idnits 2.17.1 draft-ietf-ospf-ospfv6-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 93 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 2410 instances of lines with control characters in the document. == There are 31 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 2628 has weird spacing: '...et link types...' -- 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 (October 1999) is 8958 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) == Unused Reference: 'Ref2' is defined on line 2211, but no explicit reference was found in the text == Unused Reference: 'Ref4' is defined on line 2217, but no explicit reference was found in the text == Unused Reference: 'Ref6' is defined on line 2225, but no explicit reference was found in the text == Unused Reference: 'Ref13' is defined on line 2247, but no explicit reference was found in the text == Unused Reference: 'Ref16' is defined on line 2258, but no explicit reference was found in the text == Unused Reference: 'Ref17' is defined on line 2263, but no explicit reference was found in the text == Unused Reference: 'Ref18' is defined on line 2266, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref1' ** Downref: Normative reference to an Unknown state RFC: RFC 905 (ref. 'Ref2') ** Obsolete normative reference: RFC 2233 (ref. 'Ref3') (Obsoleted by RFC 2863) ** Obsolete normative reference: RFC 1519 (ref. 'Ref4') (Obsoleted by RFC 4632) ** Downref: Normative reference to an Historic RFC: RFC 1745 (ref. 'Ref5') ** Obsolete normative reference: RFC 1700 (ref. 'Ref6') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1586 (ref. 'Ref7') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref8' ** Obsolete normative reference: RFC 1587 (ref. 'Ref9') (Obsoleted by RFC 3101) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref10' ** Obsolete normative reference: RFC 1771 (ref. 'Ref13') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2460 (ref. 'Ref14') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. 'Ref15') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2463 (ref. 'Ref16') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2461 (ref. 'Ref17') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 1981 (ref. 'Ref18') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2402 (ref. 'Ref19') (Obsoleted by RFC 4302, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref20' Summary: 20 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Coltun 2 Internet Draft Siara Systems 3 Expiration Date: April 2000 D. Ferguson 4 File name: draft-ietf-ospf-ospfv6-08.txt Juniper Networks 5 Network Working Group J. Moy 6 Internet Draft Sycamore Networks 7 October 1999 9 OSPF for IPv6 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes the modifications to OSPF to support version 35 6 of the Internet Protocol (IPv6). The fundamental mechanisms of 36 OSPF (flooding, DR election, area support, SPF calculations, etc.) 37 remain unchanged. However, some changes have been necessary, either 38 due to changes in protocol semantics between IPv4 and IPv6, or 39 simply to handle the increased address size of IPv6. 41 Changes between OSPF for IPv4 and this document include the 42 following. Addressing semantics have been removed from OSPF packets 43 and the basic LSAs. New LSAs have been created to carry IPv6 44 addresses and prefixes. OSPF now runs on a per-link basis, instead 45 of on a per-IP-subnet basis. Flooding scope for LSAs has been 46 generalized. Authentication has been removed from the OSPF protocol 47 itself, instead relying on IPv6's Authentication Header and 48 Encapsulating Security Payload. 50 Most packets in OSPF for IPv6 are almost as compact as those in OSPF 51 for IPv4, even with the larger IPv6 addresses. Most field- and 52 packet-size limitations present in OSPF for IPv4 have been relaxed. 53 In addition, option handling has been made more flexible. 55 All of OSPF for IPv4's optional capabilities, including on-demand 56 circuit support, NSSA areas, and the multicast extensions to OSPF 57 (MOSPF) are also supported in OSPF for IPv6. 59 Please send comments to ospf@discuss.microsoft.com. 61 Table of Contents 63 1 Introduction ........................................... 5 64 1.1 Terminology ............................................ 5 65 2 Differences from OSPF for IPv4 ......................... 5 66 2.1 Protocol processing per-link, not per-subnet ........... 5 67 2.2 Removal of addressing semantics ........................ 6 68 2.3 Addition of Flooding scope ............................. 6 69 2.4 Explicit support for multiple instances per link ....... 7 70 2.5 Use of link-local addresses ............................ 7 71 2.6 Authentication changes ................................. 8 72 2.7 Packet format changes .................................. 8 73 2.8 LSA format changes ..................................... 9 74 2.9 Handling unknown LSA types ............................ 11 75 2.10 Stub area support ..................................... 11 76 2.11 Identifying neighbors by Router ID .................... 12 77 3 Implementation details ................................ 12 78 3.1 Protocol data structures .............................. 13 79 3.1.1 The Area Data structure ............................... 14 80 3.1.2 The Interface Data structure .......................... 14 81 3.1.3 The Neighbor Data Structure ........................... 16 82 3.2 Protocol Packet Processing ............................ 16 83 3.2.1 Sending protocol packets .............................. 17 84 3.2.1.1 Sending Hello packets ................................. 18 85 3.2.1.2 Sending Database Description Packets .................. 18 86 3.2.2 Receiving protocol packets ............................ 19 87 3.2.2.1 Receiving Hello Packets ............................... 21 88 3.3 The Routing table Structure ........................... 21 89 3.3.1 Routing table lookup .................................. 22 90 3.4 Link State Advertisements ............................. 22 91 3.4.1 The LSA Header ........................................ 23 92 3.4.2 The link-state database ............................... 24 93 3.4.3 Originating LSAs ...................................... 24 94 3.4.3.1 Router-LSAs ........................................... 27 95 3.4.3.2 Network-LSAs .......................................... 29 96 3.4.3.3 Inter-Area-Prefix-LSAs ................................ 30 97 3.4.3.4 Inter-Area-Router-LSAs ................................ 31 98 3.4.3.5 AS-external-LSAs ...................................... 32 99 3.4.3.6 Link-LSAs ............................................. 34 100 3.4.3.7 Intra-Area-Prefix-LSAs ................................ 35 101 3.5 Flooding .............................................. 39 102 3.5.1 Receiving Link State Update packets ................... 39 103 3.5.2 Sending Link State Update packets ..................... 40 104 3.5.3 Installing LSAs in the database ....................... 42 105 3.6 Definition of self-originated LSAs .................... 42 106 3.7 Virtual links ......................................... 43 107 3.8 Routing table calculation ............................. 43 108 3.8.1 Calculating the shortest path tree for an area ........ 44 109 3.8.1.1 The next hop calculation .............................. 46 110 3.8.2 Calculating the inter-area routes ..................... 46 111 3.8.3 Examining transit areas' summary-LSAs ................. 46 112 3.8.4 Calculating AS external routes ........................ 47 113 3.9 Multiple interfaces to a single link .................. 47 114 References ............................................ 49 115 A OSPF data formats ..................................... 51 116 A.1 Encapsulation of OSPF packets ......................... 51 117 A.2 The Options field ..................................... 52 118 A.3 OSPF Packet Formats ................................... 55 119 A.3.1 The OSPF packet header ................................ 56 120 A.3.2 The Hello packet ...................................... 58 121 A.3.3 The Database Description packet ....................... 60 122 A.3.4 The Link State Request packet ......................... 62 123 A.3.5 The Link State Update packet .......................... 63 124 A.3.6 The Link State Acknowledgment packet .................. 64 125 A.4 LSA formats ........................................... 66 126 A.4.1 IPv6 Prefix Representation ............................ 67 127 A.4.1.1 Prefix Options ........................................ 68 128 A.4.2 The LSA header ........................................ 69 129 A.4.2.1 LS type ............................................... 71 130 A.4.3 Router-LSAs ........................................... 73 131 A.4.4 Network-LSAs .......................................... 76 132 A.4.5 Inter-Area-Prefix-LSAs ................................ 77 133 A.4.6 Inter-Area-Router-LSAs ................................ 79 134 A.4.7 AS-external-LSAs ...................................... 80 135 A.4.8 Link-LSAs ............................................. 83 136 A.4.9 Intra-Area-Prefix-LSAs ................................ 85 137 B Architectural Constants ............................... 87 138 C Configurable Constants ................................ 87 139 C.1 Global parameters ..................................... 87 140 C.2 Area parameters ....................................... 88 141 C.3 Router interface parameters ........................... 89 142 C.4 Virtual link parameters ............................... 90 143 C.5 NBMA network parameters ............................... 91 144 C.6 Point-to-MultiPoint network parameters ................ 92 145 C.7 Host route parameters ................................. 92 146 Security Considerations ............................... 93 147 Authors' Addresses .................................... 93 148 1. Introduction 150 This document describes the modifications to OSPF to support version 151 6 of the Internet Protocol (IPv6). The fundamental mechanisms of 152 OSPF (flooding, DR election, area support, SPF calculations, etc.) 153 remain unchanged. However, some changes have been necessary, either 154 due to changes in protocol semantics between IPv4 and IPv6, or 155 simply to handle the increased address size of IPv6. 157 This document is organized as follows. Section 2 describes the 158 differences between OSPF for IPv4 and OSPF for IPv6 in detail. 159 Section 3 provides implementation details for the changes. Appendix 160 A gives the OSPF for IPv6 packet and LSA formats. Appendix B lists 161 the OSPF architectural constants. Appendix C describes configuration 162 parameters. 164 1.1. Terminology 166 This document attempts to use terms from both the OSPF for IPv4 167 specification ([Ref1]) and the IPv6 protocol specifications 168 ([Ref14]). This has produced a mixed result. Most of the terms 169 used both by OSPF and IPv6 have roughly the same meaning (e.g., 170 interfaces). However, there are a few conflicts. IPv6 uses 171 "link" similarly to IPv4 OSPF's "subnet" or "network". In this 172 case, we have chosen to use IPv6's "link" terminology. "Link" 173 replaces OSPF's "subnet" and "network" in most places in this 174 document, although OSPF's Network-LSA remains unchanged (and 175 possibly unfortunately, a new Link-LSA has also been created). 177 The names of some of the OSPF LSAs have also changed. See 178 Section 2.8 for details. 180 2. Differences from OSPF for IPv4 182 Most of the algorithms from OSPF for IPv4 [Ref1] have preserved in 183 OSPF for IPv6. However, some changes have been necessary, either due 184 to changes in protocol semantics between IPv4 and IPv6, or simply to 185 handle the increased address size of IPv6. 187 The following subsections describe the differences between this 188 document and [Ref1]. 190 2.1. Protocol processing per-link, not per-subnet 192 IPv6 uses the term "link" to indicate "a communication facility 193 or medium over which nodes can communicate at the link layer" 194 ([Ref14]). "Interfaces" connect to links. Multiple IP subnets 195 can be assigned to a single link, and two nodes can talk 196 directly over a single link, even if they do not share a common 197 IP subnet (IPv6 prefix). 199 For this reason, OSPF for IPv6 runs per-link instead of the IPv4 200 behavior of per-IP-subnet. The terms "network" and "subnet" used 201 in the IPv4 OSPF specification ([Ref1]) should generally be 202 relaced by link. Likewise, an OSPF interface now connects to a 203 link instead of an IP subnet, etc. 205 This change affects the receiving of OSPF protocol packets, and 206 the contents of Hello Packets and Network-LSAs. 208 2.2. Removal of addressing semantics 210 In OSPF for IPv6, addressing semantics have been removed from 211 the OSPF protocol packets and the main LSA types, leaving a 212 network-protocol-independent core. In particular: 214 o IPv6 Addresses are not present in OSPF packets, except in 215 LSA payloads carried by the Link State Update Packets. See 216 Section 2.7 for details. 218 o Router-LSAs and Network-LSAs no longer contain network 219 addresses, but simply express topology information. See 220 Section 2.8 for details. 222 o OSPF Router IDs, Area IDs and LSA Link State IDs remain at 223 the IPv4 size of 32-bits. They can no longer be assigned as 224 (IPv6) addresses. 226 o Neighboring routers are now always identified by Router ID, 227 where previously they had been identified by IP address on 228 broadcast and NBMA "networks". 230 2.3. Addition of Flooding scope 232 Flooding scope for LSAs has been generalized and is now 233 explicitly coded in the LSA's LS type field. There are now three 234 separate flooding scopes for LSAs: 236 o Link-local scope. LSA is flooded only on the local link, and 237 no further. Used for the new Link-LSA (see Section A.4.8). 239 o Area scope. LSA is flooded throughout a single OSPF area 240 only. Used for Router-LSAs, Network-LSAs, Inter-Area-Prefix- 241 LSAs, Inter-Area-Router-LSAs and Intra-Area-Prefix-LSAs. 243 o AS scope. LSA is flooded throughout the routing domain. Used 244 for AS-external-LSAs. 246 2.4. Explicit support for multiple instances per link 248 OSPF now supports the ability to run multiple OSPF protocol 249 instances on a single link. For example, this may be required on 250 a NAP segment shared between several providers -- providers may 251 be running separate OSPF routing domains that want to remain 252 separate even though they have one or more physical network 253 segments (i.e., links) in common. In OSPF for IPv4 this was 254 supported in a haphazard fashion using the authentication fields 255 in the OSPF for IPv4 header. 257 Another use for running multiple OSPF instances is if you want, 258 for one reason or another, to have a single link belong to two 259 or more OSPF areas. 261 Support for multiple protocol instances on a link is 262 accomplished via an "Instance ID" contained in the OSPF packet 263 header and OSPF interface structures. Instance ID solely affects 264 the reception of OSPF packets. 266 2.5. Use of link-local addresses 268 IPv6 link-local addresses are for use on a single link, for 269 purposes of neighbor discovery, auto-configuration, etc. IPv6 270 routers do not forward IPv6 datagrams having link-local source 271 addresses [Ref15]. Link-local unicast addresses are assigned 272 from the IPv6 address range FF80/10. 274 OSPF for IPv6 assumes that each router has been assigned link- 275 local unicast addresses on each of the router's attached 276 physical segments. On all OSPF interfaces except virtual links, 277 OSPF packets are sent using the interface's associated link- 278 local unicast address as source. A router learns the link-local 279 addresses of all other routers attached to its links, and uses 280 these addresses as next hop information during packet 281 forwarding. 283 On virtual links, global scope or site-local IP addresses must 284 be used as the source for OSPF protocol packets. 286 Link-local addresses appear in OSPF Link-LSAs (see Section 287 3.4.3.6). However, link-local addresses are not allowed in other 288 OSPF LSA types. In particular, link-local addresses must not be 289 advertised in inter-area-prefix-LSAs (Section 3.4.3.3), AS- 290 external-LSAs (Section 3.4.3.5) or intra-area-prefix-LSAs 291 (Section 3.4.3.7). 293 2.6. Authentication changes 295 In OSPF for IPv6, authentication has been removed from OSPF 296 itself. The "AuType" and "Authentication" fields have been 297 removed from the OSPF packet header, and all authentication 298 related fields have been removed from the OSPF area and 299 interface structures. 301 When running over IPv6, OSPF relies on the IP Authentication 302 Header (see [Ref19]) and the IP Encapsulating Security Payload 303 (see [Ref20]) to ensure integrity and 304 authentication/confidentiality of routing exchanges. 306 Protection of OSPF packet exchanges against accidental data 307 corruption is provided by the standard IPv6 16-bit one's 308 complement checksum, covering the entire OSPF packet and 309 prepended IPv6 pseudo-header (see Section A.3.1). 311 2.7. Packet format changes 313 OSPF for IPv6 runs directly over IPv6. Aside from this, all 314 addressing semantics have been removed from the OSPF packet 315 headers, making it essentially "network-protocol-independent". 316 All addressing information is now contained in the various LSA 317 types only. 319 In detail, changes in OSPF packet format consist of the 320 following: 322 o The OSPF version number has been increased from 2 to 3. 324 o The Options field in Hello Packets and Database description 325 Packets has been expanded to 24-bits. 327 o The Authentication and AuType fields have been removed from 328 the OSPF packet header (see Section 2.6). 330 o The Hello packet now contains no address information at all, 331 and includes an Interface ID which the originating router 332 has assigned to uniquely identify (among its own interfaces) 333 its interface to the link. This Interface ID becomes the 334 Network-LSA's Link State ID, should the router become 335 Designated Router on the link. 337 o Two options bits, the "R-bit" and the "V6-bit", have been 338 added to the Options field for processing Router-LSAs during 339 the SPF calculation (see Section A.2). If the "R-bit" is 340 clear an OSPF speaker can participate in OSPF topology 341 distribution without being used to forward transit traffic; 342 this can be used in multi-homed hosts that want to 343 participate in the routing protocol. The V6-bit specializes 344 the R-bit; if the V6-bit is clear an OSPF speaker can 345 participate in OSPF topology distribution without being used 346 to forward IPv6 datagrams. If the R-bit is set and the 347 V6-bit is clear, IPv6 datagrams are not forwarded but 348 datagrams belonging to another protocol family may be 349 forwarded. 351 o The OSPF packet header now includes an "Instance ID" which 352 allows multiple OSPF protocol instances to be run on a 353 single link (see Section 2.4). 355 2.8. LSA format changes 357 All addressing semantics have been removed from the LSA header, 358 and from Router-LSAs and Network-LSAs. These two LSAs now 359 describe the routing domain's topology in a network-protocol- 360 independent manner. New LSAs have been added to distribute IPv6 361 address information, and data required for next hop resolution. 362 The names of some of IPv4's LSAs have been changed to be more 363 consistent with each other. 365 In detail, changes in LSA format consist of the following: 367 o The Options field has been removed from the LSA header, 368 expanded to 24 bits, and moved into the body of Router-LSAs, 369 Network-LSAs, Inter-Area-Router-LSAs and Link-LSAs. See 370 Section A.2 for details. 372 o The LSA Type field has been expanded (into the former 373 Options space) to 16 bits, with the upper three bits 374 encoding flooding scope and the handling of unknown LSA 375 types (see Section 2.9). 377 o Addresses in LSAs are now expressed as [prefix, prefix 378 length] instead of [address, mask] (see Section A.4.1). The 379 default route is expressed as a prefix with length 0. 381 o The Router and Network LSAs now have no address information, 382 and are network-protocol-independent. 384 o Router interface information may be spread across multiple 385 Router LSAs. Receivers must concatenate all the Router-LSAs 386 originated by a given router when running the SPF 387 calculation. 389 o A new LSA called the Link-LSA has been introduced. The LSAs 390 have local-link flooding scope; they are never flooded 391 beyond the link that they are associated with. Link-LSAs 392 have three purposes: 1) they provide the router's link-local 393 address to all other routers attached to the link, 2) they 394 inform other routers attached to the link of a list of IPv6 395 prefixes to associate with the link and 3) they allow the 396 router to assert a collection of Options bits to associate 397 with the Network-LSA that will be originated for the link. 398 See Section A.4.8 for details. 400 In IPv4, the router-LSA carries a router's IPv4 interface 401 addresses, the IPv4 equivalent of link-local addresses. 402 These are only used when calculating next hops during the 403 OSPF routing calculation (see Section 16.1.1 of [Ref1]), so 404 they do not need to be flooded past the local link; hence 405 using link-LSAs to distribute these addresses is more 406 efficient. Note that link-local addresses cannot be learned 407 through the reception of Hellos in all cases: on NBMA links 408 next hop routers do not necessarily exchange hellos, but 409 rather learn of each other's existence by way of the 410 Designated Router. 412 o The Options field in the Network LSA is set to the logical 413 OR of the Options that each router on the link advertises in 414 its Link-LSA. 416 o Type-3 summary-LSAs have been renamed "Inter-Area-Prefix- 417 LSAs". Type-4 summary LSAs have been renamed "Inter-Area- 418 Router-LSAs". 420 o The Link State ID in Inter-Area-Prefix-LSAs, Inter-Area- 421 Router-LSAs and AS-external-LSAs has lost its addressing 422 semantics, and now serves solely to identify individual 423 pieces of the Link State Database. All addresses or Router 424 IDs that were formerly expressed by the Link State ID are 425 now carried in the LSA bodies. 427 o Network-LSAs and Link-LSAs are the only LSAs whose Link 428 State ID carries additional meaning. For these LSAs, the 429 Link State ID is always the Interface ID of the originating 430 router on the link being described. For this reason, 431 Network-LSAs and Link-LSAs are now the only LSAs whose size 432 cannot be limited: a Network-LSA must list all routers 433 connected to the link, and a Link-LSA must list all of a 434 router's addresses on the link. 436 o A new LSA called the Intra-Area-Prefix-LSA has been 437 introduced. This LSA carries all IPv6 prefix information 438 that in IPv4 is included in Router-LSAs and Network-LSAs. 439 See Section A.4.9 for details. 441 o Inclusion of a forwarding address in AS-external-LSAs is now 442 optional, as is the inclusion of an external route tag (see 443 [Ref5]). In addition, AS-external-LSAs can now reference 444 another LSA, for inclusion of additional route attributes 445 that are outside the scope of the OSPF protocol itself. For 446 example, this can be used to attach BGP path attributes to 447 external routes as proposed in [Ref10]. 449 2.9. Handling unknown LSA types 451 Handling of unknown LSA types has been made more flexible so 452 that, based on LS type, unknown LSA types are either treated as 453 having link-local flooding scope, or are stored and flooded as 454 if they were understood (desirable for things like the proposed 455 External-Attributes-LSA in [Ref10]). This behavior is explicitly 456 coded in the LSA Handling bit of the link state header's LS type 457 field (see Section A.4.2.1). 459 The IPv4 OSPF behavior of simply discarding unknown types is 460 unsupported due to the desire to mix router capabilities on a 461 single link. Discarding unknown types causes problems when the 462 Designated Router supports fewer options than the other routers 463 on the link. 465 2.10. Stub area support 467 In OSPF for IPv4, stub areas were designed to minimize link- 468 state database and routing table sizes for the areas' internal 469 routers. This allows routers with minimal resources to 470 participate in even very large OSPF routing domains. 472 In OSPF for IPv6, the concept of stub areas is retained. In 473 IPv6, of the mandatory LSA types, stub areas carry only router- 474 LSAs, network-LSAs, Inter-Area-Prefix-LSAs, Link-LSAs, and 475 Intra-Area-Prefix-LSAs. This is the IPv6 equivalent of the LSA 476 types carried in IPv4 stub areas: router-LSAs, network-LSAs and 477 type 3 summary-LSAs. 479 However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS 480 types to be labeled "Store and flood the LSA, as if type 481 understood" (see the U-bit in Section A.4.2.1). Uncontrolled 482 introduction of such LSAs could cause a stub area's link-state 483 database to grow larger than its component routers' capacities. 485 To guard against this, the following rule regarding stub areas 486 has been established: an LSA whose LS type is unrecognized may 487 only be flooded into/throughout a stub area if both a) the LSA 488 has area or link-local flooding scope and b) the LSA has U-bit 489 set to 0. See Section 3.5 for details. 491 2.11. Identifying neighbors by Router ID 493 In OSPF for IPv6, neighboring routers on a given link are always 494 identified by their OSPF Router ID. This contrasts with the IPv4 495 behavior where neighbors on point-to-point networks and virtual 496 links are identified by their Router IDs, and neighbors on 497 broadcast, NBMA and Point-to-MultiPoint links are identified by 498 their IPv4 interface addresses. 500 This change affects the reception of OSPF packets (see Section 501 8.2 of [Ref1]), the lookup of neighbors (Section 10 of [Ref1]) 502 and the reception of Hello Packets (Section 10.5 of [Ref1]). 504 The Router ID of 0.0.0.0 is reserved, and should not be used. 506 3. Implementation details 508 When going from IPv4 to IPv6, the basic OSPF mechanisms remain 509 unchanged from those documented in [Ref1]. These mechanisms are 510 briefly outlined in Section 4 of [Ref1]. Both IPv6 and IPv4 have a 511 link-state database composed of LSAs and synchronized between 512 adjacent routers. Initial synchronization is performed through the 513 Database Exchange process, through the exchange of Database 514 Description, Link State Request and Link State Update packets. 515 Thereafter database synchronization is maintained via flooding, 516 utilizing Link State Update and Link State Acknowledgment packets. 517 Both IPv6 and IPv4 use OSPF Hello Packets to discover and maintain 518 neighbor relationships, and to elect Designated Routers and Backup 519 Designated Routers on broadcast and NBMA links. The decision as to 520 which neighbor relationships become adjacencies, along with the 521 basic ideas behind inter-area routing, importing external 522 information in AS-external-LSAs and the various routing calculations 523 are also the same. 525 In particular, the following IPv4 OSPF functionality described in 526 [Ref1] remains completely unchanged for IPv6: 528 o Both IPv4 and IPv6 use OSPF packet types described in Section 529 4.3 of [Ref1], namely: Hello, Database Description, Link State 530 Request, Link State Update and Link State Acknowledgment 531 packets. While in some cases (e.g., Hello packets) their format 532 has changed somewhat, the functions of the various packet types 533 remains the same. 535 o The system requirements for an OSPF implementation remain 536 unchanged, although OSPF for IPv6 requires an IPv6 protocol 537 stack (from the network layer on down) since it runs directly 538 over the IPv6 network layer. 540 o The discovery and maintenance of neighbor relationships, and the 541 selection and establishment of adjacencies remain the same. This 542 includes election of the Designated Router and Backup Designated 543 Router on broadcast and NBMA links. These mechanisms are 544 described in Sections 7, 7.1, 7.2, 7.3, 7.4 and 7.5 of [Ref1]. 546 o The link types (or equivalently, interface types) supported by 547 OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, 548 Point-to-MultiPoint and virtual links. 550 o The interface state machine, including the list of OSPF 551 interface states and events, and the Designated Router and 552 Backup Designated Router election algorithm, remain unchanged. 553 These are described in Sections 9.1, 9.2, 9.3 and 9.4 of [Ref1]. 555 o The neighbor state machine, including the list of OSPF neighbor 556 states and events, remain unchanged. These are described in 557 Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1]. 559 o Aging of the link-state database, as well as flushing LSAs from 560 the routing domain through the premature aging process, remains 561 unchanged from the description in Sections 14 and 14.1 of 562 [Ref1]. 564 However, some OSPF protocol mechanisms have changed, as outlined in 565 Section 2 above. These changes are explained in detail in the 566 following subsections, making references to the appropriate sections 567 of [Ref1]. 569 The following subsections provide a recipe for turning an IPv4 OSPF 570 implementation into an IPv6 OSPF implementation. 572 3.1. Protocol data structures 574 The major OSPF data structures are the same for both IPv4 and 575 IPv6: areas, interfaces, neighbors, the link-state database and 576 the routing table. The top-level data structures for IPv6 remain 577 those listed in Section 5 of [Ref1], with the following 578 modifications: 580 o All LSAs with known LS type and AS flooding scope appear in 581 the top-level data structure, instead of belonging to a 582 specific area or link. AS-external-LSAs are the only LSAs 583 defined by this specification which have AS flooding scope. 584 LSAs with unknown LS type, U-bit set to 1 (flood even when 585 unrecognized) and AS flooding scope also appear in the top- 586 level data structure. 588 3.1.1. The Area Data structure 590 The IPv6 area data structure contains all elements defined 591 for IPv4 areas in Section 6 of [Ref1]. In addition, all LSAs 592 of known type which have area flooding scope are contained 593 in the IPv6 area data structure. This always includes the 594 following LSA types: router-LSAs, network-LSAs, inter-area- 595 prefix-LSAs, inter-area-router-LSAs and intra-area-prefix- 596 LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even 597 when unrecognized) and area scope also appear in the area 598 data structure. IPv6 routers implementing MOSPF add group- 599 membership-LSAs to the area data structure. Type-7-LSAs 600 belong to an NSSA area's data structure. 602 3.1.2. The Interface Data structure 604 In OSPF for IPv6, an interface connects a router to a link. 605 The IPv6 interface structure modifies the IPv4 interface 606 structure (as defined in Section 9 of [Ref1]) as follows: 608 Interface ID 609 Every interface is assigned an Interface ID, which 610 uniquely identifies the interface with the router. For 611 example, some implementations may be able to use the 612 MIB-II IfIndex ([Ref3]) as Interface ID. The Interface 613 ID appears in Hello packets sent out the interface, the 614 link-local-LSA originated by router for the attached 615 link, and the router-LSA originated by the router-LSA 616 for the associated area. It will also serve as the Link 617 State ID for the network-LSA that the router will 618 originate for the link if the router is elected 619 Designated Router. 621 Instance ID 622 Every interface is assigned an Instance ID. This should 623 default to 0, and is only necessary to assign 624 differently on those links that will contain multiple 625 separate communities of OSPF Routers. For example, 626 suppose that there are two communities of routers on a 627 given ethernet segment that you wish to keep separate. 629 The first community is given an Instance ID of 0, by 630 assigning 0 as the Instance ID of all its routers' 631 interfaces to the ethernet. An Instance ID of 1 is 632 assigned to the other routers' interfaces to the 633 ethernet. The OSPF transmit and receive processing (see 634 Section 3.2) will then keep the two communities 635 separate. 637 List of LSAs with link-local scope 638 All LSAs with link-local scope and which were 639 originated/flooded on the link belong to the interface 640 structure which connects to the link. This includes the 641 collection of the link's link-LSAs. 643 List of LSAs with unknown LS type 644 All LSAs with unknown LS type and U-bit set to 0 (if 645 unrecognized, treat the LSA as if it had link-local 646 flooding scope) are kept in the data structure for the 647 interface that received the LSA. 649 IP interface address 650 For IPv6, the IPv6 address appearing in the source of 651 OSPF packets sent out the interface is almost always a 652 link-local address. The one exception is for virtual 653 links, which must use one of the router's own site-local 654 or global IPv6 addresses as IP interface address. 656 List of link prefixes 657 A list of IPv6 prefixes can be configured for the 658 attached link. These will be advertised by the router in 659 link-LSAs, so that they can be advertised by the link's 660 Designated Router in intra-area-prefix-LSAs. 662 In OSPF for IPv6, each router interface has a single metric, 663 representing the cost of sending packets out the interface. 664 In addition, OSPF for IPv6 relies on the IP Authentication 665 Header (see [Ref19]) and the IP Encapsulating Security 666 Payload (see [Ref20]) to ensure integrity and 667 authentication/confidentiality of routing exchanges. For 668 that reason, AuType and Authentication key are not 669 associated with IPv6 OSPF interfaces. 671 Interface states, events, and the interface state machine 672 remain unchanged from IPv4, and are documented in Sections 673 9.1, 9.2 and 9.3 of [Ref1] respectively. The Designated 674 Router and Backup Designated Router election algorithm also 675 remains unchanged from the IPv4 election in Section 9.4 of 676 [Ref1]. 678 3.1.3. The Neighbor Data Structure 680 The neighbor structure performs the same function in both 681 IPv6 and IPv4. Namely, it collects all information required 682 to form an adjacency between two routers, if an adjacency 683 becomes necessary. Each neighbor structure is bound to a 684 single OSPF interface. The differences between the IPv6 685 neighbor structure and the neighbor structure defined for 686 IPv4 in Section 10 of [Ref1] are: 688 Neighbor's Interface ID 689 The Interface ID that the neighbor advertises in its 690 Hello Packets must be recorded in the neighbor 691 structure. The router will include the neighbor's 692 Interface ID in the router's router-LSA when either a) 693 advertising a point-to-point link to the neighbor or b) 694 advertising a link to a network where the neighbor has 695 become Designated Router. 697 Neighbor IP address 698 Except on virtual links, the neighbor's IP address will 699 be an IPv6 link-local address. 701 Neighbor's Designated Router 702 The neighbor's choice of Designated Router is now 703 encoded as a Router ID, instead of as an IP address. 705 Neighbor's Backup Designated Router 706 The neighbor's choice of Designated Router is now 707 encoded as a Router ID, instead of as an IP address. 709 Neighbor states, events, and the neighbor state machine 710 remain unchanged from IPv4, and are documented in Sections 711 10.1, 10.2 and 10.3 of [Ref1] respectively. The decision as 712 to which adjacencies to form also remains unchanged from the 713 IPv4 logic documented in Section 10.4 of [Ref1]. 715 3.2. Protocol Packet Processing 717 OSPF for IPv6 runs directly over IPv6's network layer. As such, 718 it is encapsulated in one or more IPv6 headers, with the Next 719 Header field of the immediately encapsulating IPv6 header set to 720 the value 89. 722 As for IPv4, in IPv6 OSPF routing protocol packets are sent 723 along adjacencies only (with the exception of Hello packets, 724 which are used to discover the adjacencies). OSPF packet types 725 and functions are the same in both IPv4 and IPv4, encoded by the 726 Type field of the standard OSPF packet header. 728 3.2.1. Sending protocol packets 730 When an IPv6 router sends an OSPF routing protocol packet, 731 it fills in the fields of the standard OSPF for IPv6 packet 732 header (see Section A.3.1) as follows: 734 Version # 735 Set to 3, the version number of the protocol as 736 documented in this specification. 738 Type 739 The type of OSPF packet, such as Link state Update or 740 Hello Packet. 742 Packet length 743 The length of the entire OSPF packet in bytes, including 744 the standard OSPF packet header. 746 Router ID 747 The identity of the router itself (who is originating 748 the packet). 750 Area ID 751 The OSPF area that the packet is being sent into. 753 Instance ID 754 The OSPF Instance ID associated with the interface that 755 the packet is being sent out of. 757 Checksum 758 The standard IPv6 16-bit one's complement checksum, 759 covering the entire OSPF packet and prepended IPv6 760 pseudo-header (see Section A.3.1). 762 Selection of OSPF routing protocol packets' IPv6 source and 763 destination addresses is performed identically to the IPv4 764 logic in Section 8.1 of [Ref1]. The IPv6 destination address 765 is chosen from among the addresses AllSPFRouters, 766 AllDRouters and the Neighbor IP address associated with the 767 other end of the adjacency (which in IPv6, for all links 768 except virtual links, is an IPv6 link-local address). 770 The sending of Link State Request Packets and Link State 771 Acknowledgment Packets remains unchanged from the IPv4 772 procedures documented in Sections 10.9 and 13.5 of [Ref1] 773 respectively. Sending Hello Packets is documented in Section 774 3.2.1.1, and the sending of Database Description Packets in 775 Section 3.2.1.2. The sending of Link State Update Packets is 776 documented in Section 3.5.2. 778 3.2.1.1. Sending Hello packets 780 IPv6 changes the way OSPF Hello packets are sent in the 781 following ways (compare to Section 9.5 of [Ref1]): 783 o Before the Hello Packet is sent out an interface, 784 the interface's Interface ID must be copied into the 785 Hello Packet. 787 o The Hello Packet no longer contains an IP network 788 mask, as OSPF for IPv6 runs per-link instead of per- 789 subnet. 791 o The choice of Designated Router and Backup 792 Designated Router are now indicated within Hellos by 793 their Router IDs, instead of by their IP interface 794 addresses. Advertising the Designated Router (or 795 Backup Designated Router) as 0.0.0.0 indicates that 796 the Designated Router (or Backup Designated Router) 797 has not yet been chosen. 799 o The Options field within Hello packets has moved 800 around, getting larger in the process. More options 801 bits are now possible. Those that must be set 802 correctly in Hello packets are: The E-bit is set if 803 and only if the interface attaches to a non-stub 804 area, the N-bit is set if and only if the interface 805 attaches to an NSSA area (see [Ref9]), and the DC- 806 bit is set if and only if the router wishes to 807 suppress the sending of future Hellos over the 808 interface (see [Ref11]). Unrecognized bits in the 809 Hello Packet's Options field should be cleared. 811 Sending Hello packets on NBMA networks proceeds for IPv6 812 in exactly the same way as for IPv4, as documented in 813 Section 9.5.1 of [Ref1]. 815 3.2.1.2. Sending Database Description Packets 817 The sending of Database Description packets differs from 818 Section 10.8 of [Ref1] in the following ways: 820 o The Options field within Database Description 821 packets has moved around, getting larger in the 822 process. More options bits are now possible. Those 823 that must be set correctly in Database Description 824 packets are: The MC-bit is set if and only if the 825 router is forwarding multicast datagrams according 826 to the MOSPF specification in [Ref7], and the DC-bit 827 is set if and only if the router wishes to suppress 828 the sending of Hellos over the interface (see 829 [Ref11]). Unrecognized bits in the Database 830 Description Packet's Options field should be 831 cleared. 833 3.2.2. Receiving protocol packets 835 Whenever an OSPF protocol packet is received by the router 836 it is marked with the interface it was received on. For 837 routers that have virtual links configured, it may not be 838 immediately obvious which interface to associate the packet 839 with. For example, consider the Router RT11 depicted in 840 Figure 6 of [Ref1]. If RT11 receives an OSPF protocol 841 packet on its interface to Network N8, it may want to 842 associate the packet with the interface to Area 2, or with 843 the virtual link to Router RT10 (which is part of the 844 backbone). In the following, we assume that the packet is 845 initially associated with the non-virtual link. 847 In order for the packet to be passed to OSPF for processing, 848 the following tests must be performed on the encapsulating 849 IPv6 headers: 851 o The packet's IP destination address must be one of the 852 IPv6 unicast addresses associated with the receiving 853 interface (this includes link-local addresses), or one 854 of the IP multicast addresses AllSPFRouters or 855 AllDRouters. 857 o The Next Header field of the immediately encapsulating 858 IPv6 header must specify the OSPF protocol (89). 860 o Any encapsulating IP Authentication Headers (see 861 [Ref19]) and the IP Encapsulating Security Payloads (see 862 [Ref20]) must be processed and/or verified to ensure 863 integrity and authentication/confidentiality of OSPF 864 routing exchanges. 866 o Locally originated packets should not be passed on to 867 OSPF. That is, the source IPv6 address should be 868 examined to make sure this is not a multicast packet 869 that the router itself generated. 871 After processing the encapsulating IPv6 headers, the OSPF 872 packet header is processed. The fields specified in the 873 header must match those configured for the receiving 874 interface. If they do not, the packet should be discarded: 876 o The version number field must specify protocol version 877 3. 879 o The standard IPv6 16-bit one's complement checksum, 880 covering the entire OSPF packet and prepended IPv6 881 pseudo-header, must be verified (see Section A.3.1). 883 o The Area ID found in the OSPF header must be verified. 884 If both of the following cases fail, the packet should 885 be discarded. The Area ID specified in the header must 886 either: 888 (1) Match the Area ID of the receiving interface. In 889 this case, unlike for IPv4, the IPv6 source 890 address is not restricted to lie on the same IP 891 subnet as the receiving interface. IPv6 OSPF runs 892 per-link, instead of per-IP-subnet. 894 (2) Indicate the backbone. In this case, the packet 895 has been sent over a virtual link. The receiving 896 router must be an area border router, and the 897 Router ID specified in the packet (the source 898 router) must be the other end of a configured 899 virtual link. The receiving interface must also 900 attach to the virtual link's configured Transit 901 area. If all of these checks succeed, the packet 902 is accepted and is from now on associated with 903 the virtual link (and the backbone area). 905 o The Instance ID specified in the OSPF header must match 906 the receiving interface's Instance ID. 908 o Packets whose IP destination is AllDRouters should only 909 be accepted if the state of the receiving interface is 910 DR or Backup (see Section 9.1). 912 After header processing, the packet is further processed 913 according to its OSPF packet type. OSPF packet types and 914 functions are the same for both IPv4 and IPv6. 916 If the packet type is Hello, it should then be further 917 processed by the Hello Protocol. All other packet types are 918 sent/received only on adjacencies. This means that the 919 packet must have been sent by one of the router's active 920 neighbors. The neighbor is identified by the Router ID 921 appearing the the received packet's OSPF header. Packets not 922 matching any active neighbor are discarded. 924 The receive processing of Database Description Packets, Link 925 State Request Packets and Link State Acknowledgment Packets 926 remains unchanged from the IPv4 procedures documented in 927 Sections 10.6, 10.7 and 13.7 of [Ref1] respectively. The 928 receiving of Hello Packets is documented in Section 3.2.2.1, 929 and the receiving of Link State Update Packets is documented 930 in Section 3.5.1. 932 3.2.2.1. Receiving Hello Packets 934 The receive processing of Hello Packets differs from 935 Section 10.5 of [Ref1] in the following ways: 937 o On all link types (e.g., broadcast, NBMA, point-to- 938 point, etc), neighbors are identified solely by 939 their OSPF Router ID. For all link types except 940 virtual links, the Neighbor IP address is set to the 941 IPv6 source address in the IPv6 header of the 942 received OSPF Hello packet. 944 o There is no longer a Network Mask field in the Hello 945 Packet. 947 o The neighbor's choice of Designated Router and 948 Backup Designated Router is now encoded as an OSPF 949 Router ID instead of an IP interface address. 951 3.3. The Routing table Structure 953 The routing table used by OSPF for IPv4 is defined in Section 11 954 of [Ref1]. For IPv6 there are analogous routing table entries: 955 there are routing table entries for IPv6 address prefixes, and 956 also for AS boundary routers. The latter routing table entries 957 are only used to hold intermediate results during the routing 958 table build process (see Section 3.8). 960 Also, to hold the intermediate results during the shortest-path 961 calculation for each area, there is a separate routing table for 962 each area holding the following entries: 964 o An entry for each router in the area. Routers are identified 965 by their OSPF router ID. These routing table entries hold 966 the set of shortest paths through a given area to a given 967 router, which in turn allows calculation of paths to the 968 IPv6 prefixes advertised by that router in Intra-area- 969 prefix-LSAs. If the router is also an area-border router, 970 these entries are also used to calculate paths for inter- 971 area address prefixes. If in addition the router is the 972 other endpoint of a virtual link, the routing table entry 973 describes the cost and viability of the virtual link. 975 o An entry for each transit link in the area. Transit links 976 have associated network-LSAs. Both the transit link and the 977 network-LSA are identified by a combination of the 978 Designated Router's Interface ID on the link and the 979 Designated Router's OSPF Router ID. These routing table 980 entries allow later calculation of paths to IP prefixes 981 advertised for the transit link in intra-area-prefix-LSAs. 983 The fields in the IPv4 OSPF routing table (see Section 11 of 984 [Ref1]) remain valid for IPv6: Optional capabilities (routers 985 only), path type, cost, type 2 cost, link state origin, and for 986 each of the equal cost paths to the destination, the next hop 987 and advertising router. 989 For IPv6, the link-state origin field in the routing table entry 990 is the router-LSA or network-LSA that has directly or indirectly 991 produced the routing table entry. For example, if the routing 992 table entry describes a route to an IPv6 prefix, the link state 993 origin is the router-LSA or network-LSA that is listed in the 994 body of the intra-area-prefix-LSA that has produced the route 995 (see Section A.4.9). 997 3.3.1. Routing table lookup 999 Routing table lookup (i.e., determining the best matching 1000 routing table entry during IP forwarding) is the same for 1001 IPv6 as for IPv4. 1003 3.4. Link State Advertisements 1005 For IPv6, the OSPF LSA header has changed slightly, with the LS 1006 type field expanding and the Options field being moved into the 1007 body of appropriate LSAs. Also, the formats of some LSAs have 1008 changed somewhat (namely router-LSAs, network-LSAs and AS- 1009 external-LSAs), while the names of other LSAs have been changed 1010 (type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and 1011 inter-area-router-LSAs respectively) and additional LSAs have 1012 been added (Link-LSAs and Intra-Area-Prefix-LSAs). Type of 1013 Service (TOS) has been removed from the OSPFv2 specification 1014 [Ref1], and is not encoded within OSPF for IPv6's LSAs. 1016 These changes will be described in detail in the following 1017 subsections. 1019 3.4.1. The LSA Header 1021 In both IPv4 and IPv6, all OSPF LSAs begin with a standard 1022 20 byte LSA header. However, the contents of this 20 byte 1023 header have changed in IPv6. The LS age, Advertising Router, 1024 LS Sequence Number, LS checksum and length fields within the 1025 LSA header remain unchanged, as documented in Sections 1026 12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1 of [Ref1] 1027 respectively. However, the following fields have changed 1028 for IPv6: 1030 Options 1031 The Options field has been removed from the standard 20 1032 byte LSA header, and into the body of router-LSAs, 1033 network-LSAs, inter-area-router-LSAs and link-LSAs. The 1034 size of the Options field has increased from 8 to 24 1035 bits, and some of the bit definitions have changed (see 1036 Section A.2). In addition a separate PrefixOptions 1037 field, 8 bits in length, is attached to each prefix 1038 advertised within the body of an LSA. 1040 LS type 1041 The size of the LS type field has increased from 8 to 16 1042 bits, with the top two bits encoding flooding scope and 1043 the next bit encoding the handling of unknown LS types. 1044 See Section A.4.2.1 for the current coding of the LS 1045 type field. 1047 Link State ID 1048 Link State ID remains at 32 bits in length, but except 1049 for network-LSAs and link-LSAs, Link State ID has shed 1050 any addressing semantics. For example, an IPv6 router 1051 originating multiple AS-external-LSAs could start by 1052 assigning the first a Link State ID of 0.0.0.1, the 1053 second a Link State ID of 0.0.0.2, and so on. Instead of 1054 the IPv4 behavior of encoding the network number within 1055 the AS-external-LSA's Link State ID, the IPv6 Link State 1056 ID simply serves as a way to differentiate multiple LSAs 1057 originated by the same router. 1059 For network-LSAs, the Link State ID is set to the 1060 Designated Router's Interface ID on the link. When a 1061 router originates a Link-LSA for a given link, its Link 1062 State ID is set equal to the router's Interface ID on 1063 the link. 1065 3.4.2. The link-state database 1067 In IPv6, as in IPv4, individual LSAs are identified by a 1068 combination of their LS type, Link State ID and Advertising 1069 Router fields. Given two instances of an LSA, the most 1070 recent instance is determined by examining the LSAs' LS 1071 Sequence Number, using LS checksum and LS age as tiebreakers 1072 (see Section 13.1 of [Ref1]). 1074 In IPv6, the link-state database is split across three 1075 separate data structures. LSAs with AS flooding scope are 1076 contained within the top-level OSPF data structure (see 1077 Section 3.1) as long as either their LS type is known or 1078 their U-bit is 1 (flood even when unrecognized); this 1079 includes the AS-external-LSAs. LSAs with area flooding scope 1080 are contained within the appropriate area structure (see 1081 Section 3.1.1) as long as either their LS type is known or 1082 their U-bit is 1 (flood even when unrecognized); this 1083 includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, 1084 inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs 1085 with unknown LS type and U-bit set to 0 and/or link-local 1086 flooding scope are contained within the appropriate 1087 interface structure (see Section 3.1.2); this includes link- 1088 LSAs. 1090 To lookup or install an LSA in the database, you first 1091 examine the LS type and the LSA's context (i.e., to which 1092 area or link does the LSA belong). This information allows 1093 you to find the correct list of LSAs, all of the same LS 1094 type, where you then search based on the LSA's Link State ID 1095 and Advertising Router. 1097 3.4.3. Originating LSAs 1099 The process of reoriginating an LSA in IPv6 is the same as 1100 in IPv4: the LSA's LS sequence number is incremented, its LS 1101 age is set to 0, its LS checksum is calculated, and the LSA 1102 is added to the link state database and flooded out the 1103 appropriate interfaces. 1105 To the list of events causing LSAs to be reoriginated, which 1106 for IPv4 is given in Section 12.4 of [Ref1], the following 1107 events and/or actions are added for IPv6: 1109 o The state of one of the router's interfaces changes. The 1110 router may need to (re)originate or flush its Link-LSA 1111 and one or more router-LSAs and/or intra-area-prefix- 1112 LSAs. 1114 o The identity of a link's Designated Router changes. The 1115 router may need to (re)originate or flush the link's 1116 network-LSA and one or more router-LSAs and/or intra- 1117 area-prefix-LSAs. 1119 o A neighbor transitions to/from "Full" state. The router 1120 may need to (re)originate or flush the link's network- 1121 LSA and one or more router-LSAs and/or intra-area- 1122 prefix-LSAs. 1124 o The Interface ID of a neighbor changes. This may cause a 1125 new instance of a router-LSA to be originated for the 1126 associated area, and the reorigination of one or more 1127 intra-area-prefix-LSAs. 1129 o A new prefix is added to an attached link, or a prefix 1130 is deleted (both through configuration). This causes the 1131 router to reoriginate its link-LSA for the link, or, if 1132 it is the only router attached to the link, causes the 1133 router to reoriginate an intra-area-prefix-LSA. 1135 o A new link-LSA is received, causing the link's 1136 collection of prefixes to change. If the router is 1137 Designated Router for the link, it originates a new 1138 intra-area-prefix-LSA. 1140 Detailed construction of the seven required IPv6 LSA types 1141 is supplied by the following subsections. In order to 1142 display example LSAs, the network map in Figure 15 of [Ref1] 1143 has been reworked to show IPv6 addressing, resulting in 1144 Figure 1. The OSPF cost of each interface is has been 1145 displayed in Figure 1. The assignment of IPv6 prefixes to 1146 network links is shown in Table 1. A single area address 1147 range has been configured for Area 1, so that outside of 1148 Area 1 all of its prefixes are covered by a single route to 1149 5f00:0000:c001::/48. The OSPF interface IDs and the link- 1150 local addresses for the router interfaces in Figure 1 are 1151 given in Table 2. 1153 .......................................... 1154 . Area 1. 1155 . + . 1156 . | . 1157 . | 3+---+1 . 1158 . N1 |--|RT1|-----+ . 1159 . | +---+ \ . 1160 . | \ ______ . 1161 . + \/ \ 1+---+ 1162 . * N3 *------|RT4|------ 1163 . + /\_______/ +---+ 1164 . | / | . 1165 . | 3+---+1 / | . 1166 . N2 |--|RT2|-----+ 1| . 1167 . | +---+ +---+ . 1168 . | |RT3|---------------- 1169 . + +---+ . 1170 . |2 . 1171 . | . 1172 . +------------+ . 1173 . N4 . 1174 .......................................... 1176 Figure 1: Area 1 with IP addresses shown 1178 Network IPv6 prefix 1179 ----------------------------------- 1180 N1 5f00:0000:c001:0200::/56 1181 N2 5f00:0000:c001:0300::/56 1182 N3 5f00:0000:c001:0100::/56 1183 N4 5f00:0000:c001:0400::/56 1185 Table 1: IPv6 link prefixes for sample network 1186 Router interface Interface ID link-local address 1187 ------------------------------------------------------- 1188 RT1 to N1 1 fe80:0001::RT1 1189 to N3 2 fe80:0002::RT1 1190 RT2 to N2 1 fe80:0001::RT2 1191 to N3 2 fe80:0002::RT2 1192 RT3 to N3 1 fe80:0001::RT3 1193 to N4 2 fe80:0002::RT3 1194 RT4 to N3 1 fe80:0001::RT4 1196 Table 2: OSPF Interface IDs and link-local addresses 1198 3.4.3.1. Router-LSAs 1200 The LS type of a router-LSA is set to the value 0x2001. 1201 Router-LSAs have area flooding scope. A router may 1202 originate one or more router-LSAs for a given area. Each 1203 router-LSA contains an integral number of interface 1204 descriptions; taken together, the collection of router- 1205 LSAs originated by the router for an area describes the 1206 collected states of all the router's interfaces to the 1207 area. When multiple router-LSAs are used, they are 1208 distinguished by their Link State ID fields. 1210 The Options field in the router-LSA should be coded as 1211 follows. The V6-bit should be set. The E-bit should be 1212 clear if and only if the attached area is an OSPF stub 1213 area. The MC-bit should be set if and only if the router 1214 is running MOSPF (see [Ref8]). The N-bit should be set 1215 if and only if the attached area is an OSPF NSSA area. 1216 The R-bit should be set. The DC-bit should be set if and 1217 only if the router can correctly process the DoNotAge 1218 bit when it appears in the LS age field of LSAs (see 1219 [Ref11]). All unrecognized bits in the Options field 1220 should be cleared 1222 To the left of the Options field, the router capability 1223 bits V, E and B should be coded according to Section 1224 12.4.1 of [Ref1]. Bit W should be coded according to 1225 [Ref8]. 1227 Each of the router's interfaces to the area are then 1228 described by appending "link descriptions" to the 1229 router-LSA. Each link description is 16 bytes long, 1230 consisting of 5 fields: (link) Type, Metric, Interface 1231 ID, Neighbor Interface ID and Neighbor Router ID (see 1232 Section A.4.3). Interfaces in state "Down" or "Loopback" 1233 are not described (although looped back interfaces can 1234 contribute prefixes to Intra-Area-Prefix-LSAs). Nor are 1235 interfaces without any full adjacencies described. All 1236 other interfaces to the area add zero, one or more link 1237 descriptions, the number and content of which depend on 1238 the interface type. Within each link description, the 1239 Metric field is always set the interface's output cost 1240 and the Interface ID field is set to the interface's 1241 OSPF Interface ID. 1243 Point-to-point interfaces 1244 If the neighboring router is fully adjacent, add a 1245 Type 1 link description (point-to-point). The 1246 Neighbor Interface ID field is set to the Interface 1247 ID advertised by the neighbor in its Hello packets, 1248 and the Neighbor Router ID field is set to the 1249 neighbor's Router ID. 1251 Broadcast and NBMA interfaces 1252 If the router is fully adjacent to the link's 1253 Designated Router, or if the router itself is 1254 Designated Router and is fully adjacent to at least 1255 one other router, add a single Type 2 link 1256 description (transit network). The Neighbor 1257 Interface ID field is set to the Interface ID 1258 advertised by the Designated Router in its Hello 1259 packets, and the Neighbor Router ID field is set to 1260 the Designated Router's Router ID. 1262 Virtual links 1263 If the neighboring router is fully adjacent, add a 1264 Type 4 link description (virtual). The Neighbor 1265 Interface ID field is set to the Interface ID 1266 advertised by the neighbor in its Hello packets, and 1267 the Neighbor Router ID field is set to the 1268 neighbor's Router ID. Note that the output cost of a 1269 virtual link is calculated during the routing table 1270 calculation (see Section 3.7). 1272 Point-to-MultiPoint interfaces 1273 For each fully adjacent neighbor associated with the 1274 interface, add a separate Type 1 link description 1275 (point-to-point) with Neighbor Interface ID field 1276 set to the Interface ID advertised by the neighbor 1277 in its Hello packets, and Neighbor Router ID field 1278 set to the neighbor's Router ID. 1280 As an example, consider the router-LSA that router RT3 1281 would originate for Area 1 in Figure 1. Only a single 1282 interface must be described, namely that which connects 1283 to the transit network N3. It assumes that RT4 has been 1284 elected Designated Router of Network N3. 1286 ; RT3's router-LSA for Area 1 1288 LS age = 0 ;newly (re)originated 1289 LS type = 0x2001 ;router-LSA 1290 Link State ID = 0 ;first fragment 1291 Advertising Router = 192.1.1.3 ;RT3's Router ID 1292 bit E = 0 ;not an AS boundary router 1293 bit B = 1 ;area border router 1294 Options = (V6-bit|E-bit|R-bit) 1295 Type = 2 ;connects to N3 1296 Metric = 1 ;cost to N3 1297 Interface ID = 1 ;RT3's Interface ID on N3 1298 Neighbor Interface ID = 1 ;RT4's Interface ID on N3 1299 Neighbor Router ID = 192.1.1.4 ; RT4's Router ID 1301 If for example another router was added to Network N4, 1302 RT3 would have to advertise a second link description 1303 for its connection to (the now transit) network N4. This 1304 could be accomplished by reoriginating the above router- 1305 LSA, this time with two link descriptions. Or, a 1306 separate router-LSA could be originated with a separate 1307 Link State ID (e.g., using a Link State ID of 1) to 1308 describe the connection to N4. 1310 Host routes no longer appear in the router-LSA, but are 1311 instead included in intra-area-prefix-LSAs. 1313 3.4.3.2. Network-LSAs 1315 The LS type of a network-LSA is set to the value 0x2002. 1316 Network-LSAs have area flooding scope. A network-LSA is 1317 originated for every broadcast or NBMA link having two 1318 or more attached routers, by the link's Designated 1319 Router. The network-LSA lists all routers attached to 1320 the link. 1322 The procedure for originating network-LSAs in IPv6 is 1323 the same as the IPv4 procedure documented in Section 1324 12.4.2 of [Ref1], with the following exceptions: 1326 o An IPv6 network-LSA's Link State ID is set to the 1327 Interface ID of the Designated Router on the link. 1329 o IPv6 network-LSAs do not contain a Network Mask. All 1330 addressing information formerly contained in the 1331 IPv4 network-LSA has now been consigned to intra- 1332 Area-Prefix-LSAs. 1334 o The Options field in the network-LSA is set to the 1335 logical OR of the Options fields contained within 1336 the link's associated link-LSAs. In this way, the 1337 network link exhibits a capability when at least one 1338 of the link's routers requests that the capability 1339 be asserted. 1341 As an example, assuming that Router RT4 has been elected 1342 Designated Router of Network N3 in Figure 1, the 1343 following network-LSA is originated: 1345 ; Network-LSA for Network N3 1347 LS age = 0 ;newly (re)originated 1348 LS type = 0x2002 ;network-LSA 1349 Link State ID = 1 ;RT4's Interface ID on N3 1350 Advertising Router = 192.1.1.4 ;RT4's Router ID 1351 Options = (V6-bit|E-bit|R-bit) 1352 Attached Router = 192.1.1.4 ;Router ID 1353 Attached Router = 192.1.1.1 ;Router ID 1354 Attached Router = 192.1.1.2 ;Router ID 1355 Attached Router = 192.1.1.3 ;Router ID 1357 3.4.3.3. Inter-Area-Prefix-LSAs 1359 The LS type of an inter-area-prefix-LSA is set to the 1360 value 0x2003. Inter-area-prefix-LSAs have area flooding 1361 scope. In IPv4, inter-area-prefix-LSAs were called type 1362 3 summary-LSAs. Each inter-area-prefix-LSA describes a 1363 prefix external to the area, yet internal to the 1364 Autonomous System. 1366 The procedure for originating inter-area-prefix-LSAs in 1367 IPv6 is the same as the IPv4 procedure documented in 1368 Sections 12.4.3 and 12.4.3.1 of [Ref1], with the 1369 following exceptions: 1371 o The Link State ID of an inter-area-prefix-LSA has 1372 lost all of its addressing semantics, and instead 1373 simply serves to distinguish multiple inter-area- 1374 prefix-LSAs that are originated by the same router. 1376 o The prefix is described by the PrefixLength, 1377 PrefixOptions and Address Prefix fields embedded 1378 within the LSA body. Network Mask is no longer 1379 specified. 1381 o The NU-bit in the PrefixOptions field should be 1382 clear. The coding of the MC-bit depends upon 1383 whether, and if so how, MOSPF is operating in the 1384 routing domain (see [Ref8]). 1386 o Link-local addresses must never be advertised in 1387 inter-area-prefix-LSAs. 1389 As an example, the following shows the inter-area- 1390 prefix-LSA that Router RT4 originates into the OSPF 1391 backbone area, condensing all of Area 1's prefixes into 1392 the single prefix 5f00:0000:c001::/48. The cost is set 1393 to 4, which is the maximum cost to all of the prefix' 1394 individual components. The prefix is padded out to an 1395 even number of 32-bit words, so that it consumes 64-bits 1396 of space instead of 48 bits. 1398 ; Inter-area-prefix-LSA for Area 1 addresses 1399 ; originated by Router RT4 into the backbone 1401 LS age = 0 ;newly (re)originated 1402 LS type = 0x2003 ;inter-area-prefix-LSA 1403 Advertising Router = 192.1.1.4 ;RT4's ID 1404 Metric = 4 ;maximum to components 1405 PrefixLength = 48 1406 PrefixOptions = 0 1407 Address Prefix = 5f00:0000:c001 ;padded to 64-bits 1409 3.4.3.4. Inter-Area-Router-LSAs 1411 The LS type of an inter-area-router-LSA is set to the 1412 value 0x2004. Inter-area-router-LSAs have area flooding 1413 scope. In IPv4, inter-area-router-LSAs were called type 1414 4 summary-LSAs. Each inter-area-router-LSA describes a 1415 path to a destination OSPF router (an ASBR) that is 1416 external to the area, yet internal to the Autonomous 1417 System. 1419 The procedure for originating inter-area-router-LSAs in 1420 IPv6 is the same as the IPv4 procedure documented in 1421 Section 12.4.3 of [Ref1], with the following exceptions: 1423 o The Link State ID of an inter-area-router-LSA is no 1424 longer the destination router's OSPF Router ID, but 1425 instead simply serves to distinguish multiple inter- 1426 area-router-LSAs that are originated by the same 1427 router. The destination router's Router ID is now 1428 found in the body of the LSA. 1430 o The Options field in an inter-area-router-LSA should 1431 be set equal to the Options field contained in the 1432 destination router's own router-LSA. The Options 1433 field thus describes the capabilities supported by 1434 the destination router. 1436 As an example, consider the OSPF Autonomous System 1437 depicted in Figure 6 of [Ref1]. Router RT4 would 1438 originate into Area 1 the following inter-area-router- 1439 LSA for destination router RT7. 1441 ; inter-area-router-LSA for AS boundary router RT7 1442 ; originated by Router RT4 into Area 1 1444 LS age = 0 ;newly (re)originated 1445 LS type = 0x2004 ;inter-area-router-LSA 1446 Advertising Router = 192.1.1.4 ;RT4's ID 1447 Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities 1448 Metric = 14 ;cost to RT7 1449 Destination Router ID = Router RT7's ID 1451 3.4.3.5. AS-external-LSAs 1453 The LS type of an AS-external-LSA is set to the value 1454 0x4005. AS-external-LSAs have AS flooding scope. Each 1455 AS-external-LSA describes a path to a prefix external to 1456 the Autonomous System. 1458 The procedure for originating AS-external-LSAs in IPv6 1459 is the same as the IPv4 procedure documented in Section 1460 12.4.4 of [Ref1], with the following exceptions: 1462 o The Link State ID of an AS-external-LSA has lost all 1463 of its addressing semantics, and instead simply 1464 serves to distinguish multiple AS-external-LSAs that 1465 are originated by the same router. 1467 o The prefix is described by the PrefixLength, 1468 PrefixOptions and Address Prefix fields embedded 1469 within the LSA body. Network Mask is no longer 1470 specified. 1472 o The NU-bit in the PrefixOptions field should be 1473 clear. The coding of the MC-bit depends upon 1474 whether, and if so how, MOSPF is operating in the 1475 routing domain (see [Ref8]). 1477 o Link-local addresses can never be advertised in AS- 1478 external-LSAs. 1480 o The forwarding address is present in the AS- 1481 external-LSA if and only if the AS-external-LSA's 1482 bit F is set. 1484 o The external route tag is present in the AS- 1485 external-LSA if and only if the AS-external-LSA's 1486 bit T is set. 1488 o The capability for an AS-external-LSA to reference 1489 another LSA has been included, by inclusion of the 1490 Referenced LS Type field and the optional Referenced 1491 Link State ID field (the latter present if and only 1492 if Referenced LS Type is non-zero). This capability 1493 is for future use; for now Referenced LS Type should 1494 be set to 0 and received non-zero values for this 1495 field should be ignored. 1497 As an example, consider the OSPF Autonomous System 1498 depicted in Figure 6 of [Ref1]. Assume that RT7 has 1499 learned its route to N12 via BGP, and that it wishes to 1500 advertise a Type 2 metric into the AS. Further assume 1501 the the IPv6 prefix for N12 is the value 1502 5f00:0000:0a00::/40. RT7 would then originate the 1503 following AS-external-LSA for the external network N12. 1504 Note that within the AS-external-LSA, N12's prefix 1505 occupies 64 bits of space, to maintain 32-bit alignment. 1507 ; AS-external-LSA for Network N12, 1508 ; originated by Router RT7 1510 LS age = 0 ;newly (re)originated 1511 LS type = 0x4005 ;AS-external-LSA 1512 Link State ID = 123 ;or something else 1513 Advertising Router = Router RT7's ID 1514 bit E = 1 ;Type 2 metric 1515 bit F = 0 ;no forwarding address 1516 bit T = 1 ;external route tag included 1517 Metric = 2 1518 PrefixLength = 40 1519 PrefixOptions = 0 1520 Referenced LS Type = 0 ;no Referenced Link State ID 1521 Address Prefix = 5f00:0000:0a00 ;padded to 64-bits 1522 External Route Tag = as per BGP/OSPF interaction 1524 3.4.3.6. Link-LSAs 1526 The LS type of a Link-LSA is set to the value 0x0008. 1527 Link-LSAs have link-local flooding scope. A router 1528 originates a separate Link-LSA for each attached link 1529 that supports 2 or more (including the originating 1530 router itself) routers. 1532 Link-LSAs have three purposes: 1) they provide the 1533 router's link-local address to all other routers 1534 attached to the link and 2) they inform other routers 1535 attached to the link of a list of IPv6 prefixes to 1536 associate with the link and 3) they allow the router to 1537 assert a collection of Options bits in the Network-LSA 1538 that will be originated for the link. 1540 A Link-LSA for a given Link L is built in the following 1541 fashion: 1543 o The Link State ID is set to the router's Interface 1544 ID on Link L. 1546 o The Router Priority of the router's interface to 1547 Link L is inserted into the Link-LSA. 1549 o The Link-LSA's Options field is set to those bits 1550 that the router wishes set in Link L's Network LSA. 1552 o The router inserts its link-local address on Link L 1553 into the Link-LSA. This information will be used 1554 when the other routers on Link L do their next hop 1555 calculations (see Section 3.8.1.1). 1557 o Each IPv6 address prefix that has been configured 1558 into the router for Link L is added to the Link-LSA, 1559 by specifying values for PrefixLength, 1560 PrefixOptions, and Address Prefix fields. 1562 After building a Link-LSA for a given link, the router 1563 installs the link-LSA into the associate interface data 1564 structure and floods the Link-LSA onto the link. All 1565 other routers on the link will receive the Link-LSA, but 1566 it will go no further. 1568 As an example, consider the Link-LSA that RT3 will build 1569 for N3 in Figure 1. Suppose that the prefix 1570 5f00:0000:c001:0100::/56 has been configured within RT3 1571 for N3. This will give rise to the following Link-LSA, 1572 which RT3 will flood onto N3, but nowhere else. Note 1573 that not all routers on N3 need be configured with the 1574 prefix; those not configured will learn the prefix when 1575 receiving RT3's Link-LSA. 1577 ; RT3's Link-LSA for N3 1579 LS age = 0 ;newly (re)originated 1580 LS type = 0x0008 ;Link-LSA 1581 Link State ID = 1 ;RT3's Interface ID on N3 1582 Advertising Router = 192.1.1.3 ;RT3's Router ID 1583 Rtr Pri = 1 ;RT3's N3 Router Priority 1584 Options = (V6-bit|E-bit|R-bit) 1585 Link-local Interface Address = fe80:0001::RT3 1586 # prefixes = 1 1587 PrefixLength = 56 1588 PrefixOptions = 0 1589 Address Prefix = 5f00:0000:c001:0100 ;pad to 64-bits 1591 3.4.3.7. Intra-Area-Prefix-LSAs 1593 The LS type of an intra-area-prefix-LSA is set to the 1594 value 0x2009. Intra-area-prefix-LSAs have area flooding 1595 scope. An intra-area-prefix-LSA has one of two 1596 functions. It associates a list of IPv6 address prefixes 1597 with a transit network link by referencing a network- 1598 LSA, or associates a list of IPv6 address prefixes with 1599 a router by referencing a router-LSA. A stub link's 1600 prefixes are associated with its attached router. 1602 A router may originate multiple intra-area-prefix-LSAs 1603 for a given area, distinguished by their Link State ID 1604 fields. Each intra-area-prefix-LSA contains an integral 1605 number of prefix descriptions. 1607 A link's Designated Router originates one or more intra- 1608 area-prefix-LSAs to advertise the link's prefixes 1609 throughout the area. For a link L, L's Designated Router 1610 builds an intra-area-prefix-LSA in the following 1611 fashion: 1613 o In order to indicate that the prefixes are to be 1614 associated with the Link L, the fields Referenced LS 1615 type, Referenced Link State ID, and Referenced 1616 Advertising Router are set to the corresponding 1617 fields in Link L's network-LSA (namely LS type, Link 1618 State ID, and Advertising Router respectively). This 1619 means that Referenced LS Type is set to 0x2002, 1620 Referenced Link State ID is set to the Designated 1621 Router's Interface ID on Link L, and Referenced 1622 Advertising Router is set to the Designated Router's 1623 Router ID. 1625 o Each Link-LSA associated with Link L is examined 1626 (these are in the Designated Router's interface 1627 structure for Link L). If the Link-LSA's Advertising 1628 Router is fully adjacent to the Designated Router, 1629 the list of prefixes in the Link-LSA is copied into 1630 the intra-area-prefix-LSA that is being built. 1631 Prefixes having the NU-bit and/or LA-bit set in 1632 their Options field should not be copied, nor should 1633 link-local addresses be copied. Each prefix is 1634 described by the PrefixLength, PrefixOptions, and 1635 Address Prefix fields. Multiple prefixes having the 1636 same PrefixLength and Address Prefix are considered 1637 to be duplicates; in this case their Prefix Options 1638 fields should be merged by logically OR'ing the 1639 fields together, and a single resulting prefix 1640 should be copied into the intra-area-prefix-LSA. The 1641 Metric field for all prefixes is set to 0. 1643 o The "# prefixes" field is set to the number of 1644 prefixes that the router has copied into the LSA. If 1645 necessary, the list of prefixes can be spread across 1646 multiple intra-area-prefix-LSAs in order to keep the 1647 LSA size small. 1649 A router builds an intra-area-prefix-LSA to advertise 1650 its own prefixes, and those of its attached stub links. 1651 A Router RTX would build its intra-area-prefix-LSA in 1652 the following fashion: 1654 o In order to indicate that the prefixes are to be 1655 associated with the Router RTX itself, RTX sets 1656 Referenced LS type to 0x2001, Referenced Link State 1657 ID to 0, and Referenced Advertising Router to RTX's 1658 own Router ID. 1660 o Router RTX examines its list of interfaces to the 1661 area. If the interface is in state Down, its 1662 prefixes are not included. If the interface has been 1663 reported in RTX's router-LSA as a Type 2 link 1664 description (link to transit network), its prefixes 1665 are not included (they will be included in the 1666 intra-area-prefix-LSA for the link instead). If the 1667 interface type is Point-to-MultiPoint, or the 1668 interface is in state Loopback, or the interface 1669 connects to a point-to-point link which has not been 1670 assigned a prefix, then the site-local and global 1671 scope IPv6 addresses associated with the interface 1672 (if any) are copied into the intra-area-prefix-LSA, 1673 setting the LA-bit in the PrefixOptions field, and 1674 setting the PrefixLength to 128 and the Metric to 0. 1675 Otherwise, the list of site-local and global 1676 prefixes configured in RTX for the link are copied 1677 into the intra-area-prefix-LSA by specifying the 1678 PrefixLength, PrefixOptions, and Address Prefix 1679 fields. The Metric field for each of these prefixes 1680 is set to the interface's output cost. 1682 o RTX adds the IPv6 prefixes for any directly attached 1683 hosts belonging to the area (see Section C.7) to the 1684 intra-area-prefix-LSA. 1686 o If RTX has one or more virtual links configured 1687 through the area, it includes one of its site-local 1688 or global scope IPv6 interface addresses in the LSA 1689 (if it hasn't already), setting the LA-bit in the 1690 PrefixOptions field, and setting the PrefixLength to 1691 128 and the Metric to 0. This information will be 1692 used later in the routing calculation so that the 1693 two ends of the virtual link can discover each 1694 other's IPv6 addresses. 1696 o The "# prefixes" field is set to the number of 1697 prefixes that the router has copied into the LSA. If 1698 necessary, the list of prefixes can be spread across 1699 multiple intra-area-prefix-LSAs in order to keep the 1700 LSA size small. 1702 For example, the intra-area-prefix-LSA originated by RT4 1703 for Network N3 (assuming that RT4 is N3's Designated 1704 Router), and the intra-area-prefix-LSA originated into 1705 Area 1 by Router RT3 for its own prefixes, are pictured 1706 below. 1708 ; Intra-area-prefix-LSA 1709 ; for network link N3 1711 LS age = 0 ;newly (re)originated 1712 LS type = 0x2009 ;Intra-area-prefix-LSA 1713 Link State ID = 5 ;or something 1714 Advertising Router = 192.1.1.4 ;RT4's Router ID 1715 # prefixes = 1 1716 Referenced LS type = 0x2002 ;network-LSA reference 1717 Referenced Link State ID = 1 1718 Referenced Advertising Router = 192.1.1.4 1719 PrefixLength = 56 ;N3's prefix 1720 PrefixOptions = 0 1721 Metric = 0 1722 Address Prefix = 5f00:0000:c001:0100 ;pad 1724 ; RT3's Intra-area-prefix-LSA 1725 ; for its own prefixes 1727 LS age = 0 ;newly (re)originated 1728 LS type = 0x2009 ;Intra-area-prefix-LSA 1729 Link State ID = 177 ;or something 1730 Advertising Router = 192.1.1.3 ;RT3's Router ID 1731 # prefixes = 1 1732 Referenced LS type = 0x2001 ;router-LSA reference 1733 Referenced Link State ID = 0 1734 Referenced Advertising Router = 192.1.1.3 1735 PrefixLength = 56 ;N4's prefix 1736 PrefixOptions = 0 1737 Metric = 2 ;N4 interface cost 1738 Address Prefix = 5f00:0000:c001:0400 ;pad 1740 When network conditions change, it may be necessary for 1741 a router to move prefixes from one intra-area-prefix-LSA 1742 to another. For example, if the router is Designated 1743 Router for a link but the link has no other attached 1744 routers, the link's prefixes are advertised in an intra- 1745 area-prefix-LSA referring to the Designated Router's 1746 router-LSA. When additional routers appear on the link, 1747 a network-LSA is originated for the link and the link's 1748 prefixes are moved to an intra-area-prefix-LSA referring 1749 to the network-LSA. 1751 Note that in the intra-area-prefix-LSA, the "Referenced 1752 Advertising Router" is always equal to the router that 1753 is originating the intra-area-prefix-LSA (i.e., the 1754 LSA's Advertising Router). The reason that the 1755 Referenced Advertising Router field appears is that, 1756 even though it is currently redundant, it may not be in 1757 the future. We may sometime want to use the same LSA 1758 format to advertise address prefixes for other protocol 1759 suites. In that event, the Designated Router may not be 1760 running the other protocol suite, and so another of the 1761 link's routers may need to send out the prefix-LSA. In 1762 that case, "Referenced Advertising Router" and 1763 "Advertising Router" would be different. 1765 3.5. Flooding 1767 Most of the flooding algorithm remains unchanged from the IPv4 1768 flooding mechanisms described in Section 13 of [Ref1]. In 1769 particular, the processes for determining which LSA instance is 1770 newer (Section 13.1 of [Ref1]), responding to updates of self- 1771 originated LSAs (Section 13.4 of [Ref1]), sending Link State 1772 Acknowledgment packets (Section 13.5 of [Ref1]), retransmitting 1773 LSAs (Section 13.6 of [Ref1]) and receiving Link State 1774 Acknowledgment packets (Section 13.7 of [Ref1]) are exactly the 1775 same for IPv6 and IPv4. 1777 However, the addition of flooding scope and handling options for 1778 unrecognized LSA types (see Section A.4.2.1) has caused some 1779 changes in the OSPF flooding algorithm: the reception of Link 1780 State Updates (Section 13 in [Ref1]) and the sending of Link 1781 State Updates (Section 13.3 of [Ref1]) must take into account 1782 the LSA's scope and U-bit setting. Also, installation of LSAs 1783 into the OSPF database (Section 13.2 of [Ref1]) causes different 1784 events in IPv6, due to the reorganization of LSA types and 1785 contents in IPv6. These changes are described in detail below. 1787 3.5.1. Receiving Link State Update packets 1789 The encoding of flooding scope in the LS type and the need 1790 to process unknown LS types causes modifications to the 1791 processing of received Link State Update packets. As in 1792 IPv4, each LSA in a received Link State Update packet is 1793 examined. In IPv4, eight steps are executed for each LSA, as 1794 described in Section 13 of [Ref1]. For IPv6, all the steps 1795 are the same, except that Steps 2 and 3 are modified as 1796 follows: 1798 (2) Examine the LSA's LS type. If the LS type is 1799 unknown, the area has been configured as a stub area, 1800 and either the LSA's flooding scope is set to "AS 1801 flooding scope" or the U-bit of the LS type is set to 1802 1 (flood even when unrecognized), then discard the 1803 LSA and get the next one from the Link State Update 1804 Packet. This generalizes the IPv4 behavior where AS- 1805 external-LSAs are not flooded into/throughout stub 1806 areas. 1808 (3) Else if the flooding scope of the LSA is set to 1809 "reserved", discard the LSA and get the next one from 1810 the Link State Update Packet. 1812 Steps 5b (sending Link State Update packets) and 5d 1813 (installing LSAs in the link state database) in Section 13 1814 of [Ref1] are also somewhat different for IPv6, as described 1815 in Sections 3.5.2 and 3.5.3 below. 1817 3.5.2. Sending Link State Update packets 1819 The sending of Link State Update packets is described in 1820 Section 13.3 of [Ref1]. For IPv4 and IPv6, the steps for 1821 sending a Link State Update packet are the same (steps 1 1822 through 5 of Section 13.3 in [Ref1]). However, the list of 1823 eligible interfaces out which to flood the LSA is different. 1824 For IPv6, the eligible interfaces are selected based on the 1825 following factors: 1827 o The LSA's flooding scope. 1829 o For LSAs with area or link-local flooding scoping, the 1830 particular area or interface that the LSA is associated 1831 with. 1833 o Whether the LSA has a recognized LS type. 1835 o The setting of the U-bit in the LS type. If the U-bit is 1836 set to 0, unrecognized LS types are treated as having 1837 link-local scope. If set to 1, unrecognized LS types are 1838 stored and flooded as if they were recognized. 1840 Choosing the set of eligible interfaces then breaks into the 1841 following cases: 1843 Case 1 1844 The LSA's LS type is recognized. In this case, the set 1845 of eligible interfaces is set depending on the flooding 1846 scope encoded in the LS type. If the flooding scope is 1847 "AS flooding scope", the eligible interfaces are all 1848 router interfaces excepting virtual links. In addition, 1849 AS-external-LSAs are not flooded out interfaces 1850 connecting to stub areas. If the flooding scope is "area 1851 flooding scope", the set of eligible interfaces are 1852 those interfaces connecting to the LSA's associated 1853 area. If the flooding scope is "link-local flooding 1854 scope", then there is a single eligible interface, the 1855 one connecting to the LSA's associated link (which, when 1856 the LSA is received in a Link State Update packet, is 1857 also the interface the LSA was received on). 1859 Case 2 1860 The LS type is unrecognized, and the U-bit in the LS 1861 Type is set to 0 (treat the LSA as if it had link-local 1862 flooding scope). In this case there is a single eligible 1863 interface, namely, the interface on which the LSA was 1864 received. 1866 Case 3 1867 The LS type is unrecognized, and the U-bit in the LS 1868 Type is set to 1 (store and flood the LSA, as if type 1869 understood). In this case, select the eligible 1870 interfaces based on the encoded flooding scope as in 1871 Case 1 above. However, in this case interfaces attached 1872 to stub areas are always excluded. 1874 A further decision must sometimes be made before adding an 1875 LSA to a given neighbor's link-state retransmission list 1876 (Step 1d in Section 13.3 of [Ref1]). If the LS type is 1877 recognized by the router, but not by the neighbor (as can be 1878 determined by examining the Options field that the neighbor 1879 advertised in its Database Description packet) and the LSA's 1880 U-bit is set to 0, then the LSA should be added to the 1881 neighbor's link-state retransmission list if and only if 1882 that neighbor is the Designated Router or Backup Designated 1883 Router for the attached link. The LS types described in 1884 detail by this memo, namely router-LSAs (LS type 0x2001), 1885 network-LSAs (0x2002), Inter-Area-Prefix-LSAs (0x2003), 1886 Inter-Area-Router-LSAs (0x2004), AS-External-LSAs (0x4005), 1887 Link-LSAs (0x0008) and Intra-Area-Prefix-LSAs (0x2009) are 1888 assumed to be understood by all routers. However, as an 1889 example the group-membership-LSA (0x2006) is understood only 1890 by MOSPF routers and since it has its U-bit set to 0, it 1891 should only be forwarded to a non-MOSPF neighbor (determined 1892 by examining the MC-bit in the neighbor's Database 1893 Description packets' Options field) when the neighbor is 1894 Designated Router or Backup Designated Router for the 1895 attached link. 1897 The previous paragraph solves a problem in IPv4 OSPF 1898 extensions such as MOSPF, which require that the Designated 1899 Router support the extension in order to have the new LSA 1900 types flooded across broadcast and NBMA networks (see 1901 Section 10.2 of [Ref8]). 1903 3.5.3. Installing LSAs in the database 1905 There are three separate places to store LSAs, depending on 1906 their flooding scope. LSAs with AS flooding scope are stored 1907 in the global OSPF data structure (see Section 3.1) as long 1908 as their LS type is known or their U-bit is 1. LSAs with 1909 area flooding scope are stored in the appropriate area data 1910 structure (see Section 3.1.1) as long as their LS type is 1911 known or their U-bit is 1. LSAs with link-local flooding 1912 scope, and those LSAs with unknown LS type and U-bit set to 1913 0 (treat the LSA as if it had link-local flooding scope) are 1914 stored in the appropriate interface structure. 1916 When storing the LSA into the link-state database, a check 1917 must be made to see whether the LSA's contents have changed. 1918 Changes in contents are indicated exactly as in Section 13.2 1919 of [Ref1]. When an LSA's contents have been changed, the 1920 following parts of the routing table must be recalculated, 1921 based on the LSA's LS type: 1923 Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs and Link- 1924 LSAs 1925 The entire routing table is recalculated, starting with 1926 the shortest path calculation for each area (see Section 1927 3.8). 1929 Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs 1930 The best route to the destination described by the LSA 1931 must be recalculated (see Section 16.5 in [Ref1]). If 1932 this destination is an AS boundary router, it may also 1933 be necessary to re-examine all the AS-external-LSAs. 1935 AS-external-LSAs 1936 The best route to the destination described by the AS- 1937 external-LSA must be recalculated (see Section 16.6 in 1938 [Ref1]). 1940 As in IPv4, any old instance of the LSA must be removed from 1941 the database when the new LSA is installed. This old 1942 instance must also be removed from all neighbors' Link state 1943 retransmission lists. 1945 3.6. Definition of self-originated LSAs 1947 In IPv6 the definition of a self-originated LSA has been 1948 simplified from the IPv4 definition appearing in Sections 13.4 1949 and 14.1 of [Ref1]. For IPv6, self-originated LSAs are those 1950 LSAs whose Advertising Router is equal to the router's own 1951 Router ID. 1953 3.7. Virtual links 1955 OSPF virtual links for IPv4 are described in Section 15 of 1956 [Ref1]. Virtual links are the same in IPv6, with the following 1957 exceptions: 1959 o LSAs having AS flooding scope are never flooded over virtual 1960 adjacencies, nor are LSAs with AS flooding scope summarized 1961 over virtual adjacencies during the Database Exchange 1962 process. This is a generalization of the IPv4 treatment of 1963 AS-external-LSAs. 1965 o The IPv6 interface address of a virtual link must be an IPv6 1966 address having site-local or global scope, instead of the 1967 link-local addresses used by other interface types. This 1968 address is used as the IPv6 source for OSPF protocol packets 1969 sent over the virtual link. 1971 o Likewise, the virtual neighbor's IPv6 address is an IPv6 1972 address with site-local or global scope. To enable the 1973 discovery of a virtual neighbor's IPv6 address during the 1974 routing calculation, the neighbor advertises its virtual 1975 link's IPv6 interface address in an Intra-Area-Prefix-LSA 1976 originated for the virtual link's transit area (see Sections 1977 3.4.3.7 and 3.8.1). 1979 o Like all other IPv6 OSPF interfaces, virtual links are 1980 assigned unique (within the router) Interface IDs. These are 1981 advertised in Hellos sent over the virtual link, and in the 1982 router's router-LSAs. 1984 3.8. Routing table calculation 1986 The IPv6 OSPF routing calculation proceeds along the same lines 1987 as the IPv4 OSPF routing calculation, following the five steps 1988 specified by Section 16 of [Ref1]. High level differences 1989 between the IPv6 and IPv4 calculations include: 1991 o Prefix information has been removed from router-LSAs, and 1992 now is advertised in intra-area-prefix-LSAs. Whenever [Ref1] 1993 specifies that stub networks within router-LSAs be examined, 1994 IPv6 will instead examine prefixes within intra-area-prefix- 1995 LSAs. 1997 o Type 3 and 4 summary-LSAs have been renamed inter-area- 1998 prefix-LSAs and inter-area-router-LSAs (respectively). 2000 o Addressing information is no longer encoded in Link State 2001 IDs, and must instead be found within the body of LSAs. 2003 o In IPv6, a router can originate multiple router-LSAs within 2004 a single area, distinguished by Link State ID. These router- 2005 LSAs must be treated as a single aggregate by the area's 2006 shortest path calculation (see Section 3.8.1). 2008 For each area, routing table entries have been created for the 2009 area's routers and transit links, in order to store the results 2010 of the area's shortest-path tree calculation (see Section 2011 3.8.1). These entries are then used when processing intra-area- 2012 prefix-LSAs, inter-area-prefix-LSAs and inter-area-router-LSAs, 2013 as described in Section 3.8.2. 2015 Events generated as a result of routing table changes (Section 2016 16.7 of [Ref1]), and the equal-cost multipath logic (Section 2017 16.8 of [Ref1]) are identical for both IPv4 and IPv6. 2019 3.8.1. Calculating the shortest path tree for an area 2021 The IPv4 shortest path calculation is contained in Section 2022 16.1 of [Ref1]. The graph used by the shortest-path tree 2023 calculation is identical for both IPv4 and IPv6. The graph's 2024 vertices are routers and transit links, represented by 2025 router-LSAs and network-LSAs respectively. A router is 2026 identified by its OSPF Router ID, while a transit link is 2027 identified by its Designated Router's Interface ID and OSPF 2028 Router ID. Both routers and transit links have associated 2029 routing table entries within the area (see Section 3.3). 2031 Section 16.1 of [Ref1] splits up the shortest path 2032 calculations into two stages. First the Dijkstra calculation 2033 is performed, and then the stub links are added onto the 2034 tree as leaves. The IPv6 calculation maintains this split. 2036 The Dijkstra calculation for IPv6 is identical to that 2037 specified for IPv4, with the following exceptions 2038 (referencing the steps from the Dijkstra calculation as 2039 described in Section 16.1 of [Ref1]): 2041 o The Vertex ID for a router is the OSPF Router ID. The 2042 Vertex ID for a transit network is a combination of the 2043 Interface ID and OSPF Router ID of the network's 2044 Designated Router. 2046 o In Step 2, when a router Vertex V has just been added to 2047 the shortest path tree, there may be multiple LSAs 2048 associated with the router. All Router-LSAs with 2049 Advertising Router set to V's OSPF Router ID must 2050 processed as an aggregate, treating them as fragments of 2051 a single large router-LSA. The Options field and the 2052 router type bits (bits W, V, E and B) should always be 2053 taken from "fragment" with the smallest Link State ID. 2055 o Step 2a is not needed in IPv6, as there are no longer 2056 stub network links in router-LSAs. 2058 o In Step 2b, if W is a router, there may again be 2059 multiple LSAs associated with the router. All Router- 2060 LSAs with Advertising Router set to W's OSPF Router ID 2061 must processed as an aggregate, treating them as 2062 fragments of a single large router-LSA. 2064 o In Step 4, there are now per-area routing table entries 2065 for each of an area's routers, instead of just the area 2066 border routers. These entries subsume all the 2067 functionality of IPv4's area border router routing table 2068 entries, including the maintenance of virtual links. 2069 When the router added to the area routing table in this 2070 step is the other end of a virtual link, the virtual 2071 neighbor's IP address is set as follows: The collection 2072 of intra-area-prefix-LSAs originated by the virtual 2073 neighbor is examined, with the virtual neighbor's IP 2074 address being set to the first prefix encountered having 2075 the "LA-bit" set. 2077 o Routing table entries for transit networks, which are no 2078 longer associated with IP networks, are also modified in 2079 Step 4. 2081 The next stage of the shortest path calculation proceeds 2082 similarly to the two steps of the second stage of Section 2083 16.1 in [Ref1]. However, instead of examining the stub links 2084 within router-LSAs, the list of the area's intra-area- 2085 prefix-LSAs is examined. A prefix advertisement whose "NU- 2086 bit" is set should not be included in the routing 2087 calculation. The cost of any advertised prefix is the sum of 2088 the prefix' advertised metric plus the cost to the transit 2089 vertex (either router or transit network) identified by 2090 intra-area-prefix-LSA's Referenced LS type, Referenced Link 2091 State ID and Referenced Advertising Router fields. This 2092 latter cost is stored in the transit vertex' routing table 2093 entry for the area. 2095 3.8.1.1. The next hop calculation 2097 In IPv6, the calculation of the next hop's IPv6 address 2098 (which will be a link-local address) proceeds along the 2099 same lines as the IPv4 next hop calculation (see Section 2100 16.1.1 of [Ref1]). The only difference is in calculating 2101 the next hop IPv6 address for a router (call it Router 2102 X) which shares a link with the calculating router. In 2103 this case the calculating router assigns the next hop 2104 IPv6 address to be the link-local interface address 2105 contained in Router X's Link-LSA (see Section A.4.8) for 2106 the link. This procedure is necessary since on some 2107 links, such as NBMA links, the two routers need not be 2108 neighbors, and therefore might not be exchanging OSPF 2109 Hellos. 2111 3.8.2. Calculating the inter-area routes 2113 Calculation of inter-area routes for IPv6 proceeds along the 2114 same lines as the IPv4 calculation in Section 16.2 of 2115 [Ref1], with the following modifications: 2117 o The names of the Type 3 summary-LSAs and Type 4 summary- 2118 LSAs have been changed to inter-area-prefix-LSAs and 2119 inter-area-router-LSAs respectively. 2121 o The Link State ID of the above LSA types no longer 2122 encodes the network or router described by the LSA. 2123 Instead, an address prefix is contained in the body of 2124 an inter-area-prefix-LSA, and a described router's OSPF 2125 Router ID is carried in the body of an inter-area- 2126 router-LSA. 2128 o Prefixes having the "NU-bit" set in their Prefix Options 2129 field should be ignored by the inter-area route 2130 calculation. 2132 When a single inter-area-prefix-LSA or inter-area-router-LSA 2133 has changed, the incremental calculations outlined in 2134 Section 16.5 of [Ref1] can be performed instead of 2135 recalculating the entire routing table. 2137 3.8.3. Examining transit areas' summary-LSAs 2139 Examination of transit areas' summary-LSAs in IPv6 proceeds 2140 along the same lines as the IPv4 calculation in Section 16.3 2141 of [Ref1], modified in the same way as the IPv6 inter-area 2142 route calculation in Section 3.8.2. 2144 3.8.4. Calculating AS external routes 2146 The IPv6 AS external route calculation proceeds along the 2147 same lines as the IPv4 calculation in Section 16.4 of 2148 [Ref1], with the following exceptions: 2150 o The Link State ID of the AS-external-LSA types no longer 2151 encodes the network described by the LSA. Instead, an 2152 address prefix is contained in the body of an AS- 2153 external-LSA. 2155 o The default route is described by AS-external-LSAs which 2156 advertise zero length prefixes. 2158 o Instead of comparing the AS-external-LSA's Forwarding 2159 address field to 0.0.0.0 to see whether a forwarding 2160 address has been used, bit F of the external-LSA is 2161 examined. A forwarding address is in use if and only if 2162 bit F is set. 2164 o Prefixes having the "NU-bit" set in their Prefix Options 2165 field should be ignored by the inter-area route 2166 calculation. 2168 When a single AS-external-LSA has changed, the incremental 2169 calculations outlined in Section 16.6 of [Ref1] can be 2170 performed instead of recalculating the entire routing table. 2172 3.9. Multiple interfaces to a single link 2174 In OSPF for IPv6, a router may have multiple interfaces to a 2175 single link. All interfaces are involved in the reception and 2176 transmission of data traffic, however only a single interface 2177 sends and receives OSPF control traffic. In more detail: 2179 o Each of the multiple interfaces are assigned different 2180 Interface IDs. In this way the router can automatically 2181 detect when multiple interfaces attach to the same link, 2182 when receiving Hellos from its own Router ID but with an 2183 Interface ID other than the receiving interface's. 2185 o The router turns off the sending and receiving of OSPF 2186 packets (that is, control traffic) on all but one of the 2187 interfaces to the link. The choice of interface to send and 2188 receive control traffic is implementation dependent; as one 2189 example, the interface with the highest Interface ID could 2190 be chosen. If the router is elected DR, it will be this 2191 interface's Interface ID that will be used as the network- 2192 LSA's Link State ID. 2194 o All the multiple interfaces to the link will however appear 2195 in the router-LSA. In addition, a Link-LSA will be generated 2196 for each of the multiple interfaces. In this way, all 2197 interfaces will be included in OSPF's routing calculations. 2199 o If the interface which is responsible for sending and 2200 receiving control traffic fails, another will have to take 2201 over, reforming all neighbor adjacencies from scratch. This 2202 failure can be detected by the router itself, when the other 2203 interfaces to the same link cease to hear the router's own 2204 Hellos. 2206 References 2208 [Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, Ascend 2209 Communications, Inc., April 1998. 2211 [Ref2] McKenzie, A., "ISO Transport Protocol specification ISO DP 2212 8073", RFC 905, ISO, April 1984. 2214 [Ref3] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB 2215 using SMIv2", RFC 2233, November 1997. 2217 [Ref4] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter- 2218 Domain Routing (CIDR): an Address Assignment and Aggregation 2219 Strategy", RFC1519, BARRNet, cisco, MERIT, OARnet, September 2220 1993. 2222 [Ref5] Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for 2223 IP---OSPF Interaction", RFC1745, December 1994 2225 [Ref6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 2226 1700, USC/Information Sciences Institute, October 1994. 2228 [Ref7] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 2229 Over Frame Relay Networks", RFC 1586, March 1994. 2231 [Ref8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 2232 Inc., March 1994. 2234 [Ref9] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 2235 RainbowBridge Communications, Stanford University, March 2236 1994. 2238 [Ref10] Ferguson, D., "The OSPF External Attributes LSA", 2239 unpublished. 2241 [Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 2242 1793, Cascade, April 1995. 2244 [Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 2245 DECWRL, Stanford University, November 1990. 2247 [Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 2248 (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp., 2249 cisco Systems, March 1995. 2251 [Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2252 (IPv6) Specification", RFC 2460, Cisco, Nokia, December 2253 1998. 2255 [Ref15] Hinden R. and S. Deering, "IP Version 6 Addressing 2256 Architecture", RFC 2373, Nokia, Cisco Systems, July 1998. 2258 [Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol 2259 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2260 Specification" RFC 2463, Lucent, Cisco Systems, December 2261 1998. 2263 [Ref17] Narten, T., E. Nordmark and W. Simpson, "Neighbor Discovery 2264 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2266 [Ref18] McCann, J., S. Deering and J. Mogul, "Path MTU Discovery for 2267 IP version 6", RFC 1981, August 1996. 2269 [Ref19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2270 2402, BBN Corp, @Home Network, November 1998. 2272 [Ref20] Kent S. and R. Atkinson, "IP Encapsulating Security Payload 2273 (ESP)", RFC 2406, BBN Corp, @Home Network, November 1998. 2275 A. OSPF data formats 2277 This appendix describes the format of OSPF protocol packets and OSPF 2278 LSAs. The OSPF protocol runs directly over the IPv6 network layer. 2279 Before any data formats are described, the details of the OSPF 2280 encapsulation are explained. 2282 Next the OSPF Options field is described. This field describes 2283 various capabilities that may or may not be supported by pieces of 2284 the OSPF routing domain. The OSPF Options field is contained in OSPF 2285 Hello packets, Database Description packets and in OSPF LSAs. 2287 OSPF packet formats are detailed in Section A.3. 2289 A description of OSPF LSAs appears in Section A.4. This section 2290 describes how IPv6 address prefixes are represented within LSAs, 2291 details the standard LSA header, and then provides formats for each 2292 of the specific LSA types. 2294 A.1 Encapsulation of OSPF packets 2296 OSPF runs directly over the IPv6's network layer. OSPF packets are 2297 therefore encapsulated solely by IPv6 and local data-link headers. 2299 OSPF does not define a way to fragment its protocol packets, and 2300 depends on IPv6 fragmentation when transmitting packets larger than 2301 the link MTU. If necessary, the length of OSPF packets can be up to 2302 65,535 bytes. The OSPF packet types that are likely to be large 2303 (Database Description Packets, Link State Request, Link State 2304 Update, and Link State Acknowledgment packets) can usually be split 2305 into several separate protocol packets, without loss of 2306 functionality. This is recommended; IPv6 fragmentation should be 2307 avoided whenever possible. Using this reasoning, an attempt should 2308 be made to limit the sizes of OSPF packets sent over virtual links 2309 to 1280 bytes unless Path MTU Discovery is being performed [Ref14]. 2311 The other important features of OSPF's IPv6 encapsulation are: 2313 o Use of IPv6 multicast. Some OSPF messages are multicast, when 2314 sent over broadcast networks. Two distinct IP multicast 2315 addresses are used. Packets sent to these multicast addresses 2316 should never be forwarded; they are meant to travel a single hop 2317 only. As such, the multicast addresses have been chosen with 2318 link-local scope, and packets sent to these addresses should 2319 have their IPv6 Hop Limit set to 1. 2321 AllSPFRouters 2322 This multicast address has been assigned the value FF02::5. 2324 All routers running OSPF should be prepared to receive 2325 packets sent to this address. Hello packets are always sent 2326 to this destination. Also, certain OSPF protocol packets 2327 are sent to this address during the flooding procedure. 2329 AllDRouters 2330 This multicast address has been assigned the value FF02::6. 2331 Both the Designated Router and Backup Designated Router must 2332 be prepared to receive packets destined to this address. 2333 Certain OSPF protocol packets are sent to this address 2334 during the flooding procedure. 2336 o OSPF is IP protocol 89. This number should be inserted in the 2337 Next Header field of the encapsulating IPv6 header. 2339 A.2 The Options field 2341 The 24-bit OSPF Options field is present in OSPF Hello packets, 2342 Database Description packets and certain LSAs (router-LSAs, network- 2343 LSAs, inter-area-router-LSAs and link-LSAs). The Options field 2344 enables OSPF routers to support (or not support) optional 2345 capabilities, and to communicate their capability level to other 2346 OSPF routers. Through this mechanism routers of differing 2347 capabilities can be mixed within an OSPF routing domain. 2349 An option mismatch between routers can cause a variety of behaviors, 2350 depending on the particular option. Some option mismatches prevent 2351 neighbor relationships from forming (e.g., the E-bit below); these 2352 mismatches are discovered through the sending and receiving of Hello 2353 packets. Some option mismatches prevent particular LSA types from 2354 being flooded across adjacencies (e.g., the MC-bit below); these are 2355 discovered through the sending and receiving of Database Description 2356 packets. Some option mismatches prevent routers from being included 2357 in one or more of the various routing calculations because of their 2358 reduced functionality (again the MC-bit is an example); these 2359 mismatches are discovered by examining LSAs. 2361 Six bits of the OSPF Options field have been assigned. Each bit is 2362 described briefly below. Routers should reset (i.e. clear) 2363 unrecognized bits in the Options field when sending Hello packets or 2364 Database Description packets and when originating LSAs. Conversely, 2365 routers encountering unrecognized Option bits in received Hello 2366 Packets, Database Description packets or LSAs should ignore the 2367 capability and process the packet/LSA normally. 2369 1 2 2370 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 2372 | | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6| 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 2375 The Options field 2377 V6-bit 2378 If this bit is clear, the router/link should be excluded from 2379 IPv6 routing calculations. See Section 3.8 of this memo. 2381 E-bit 2382 This bit describes the way AS-external-LSAs are flooded, as 2383 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [Ref1]. 2385 MC-bit 2386 This bit describes whether IP multicast datagrams are forwarded 2387 according to the specifications in [Ref7]. 2389 N-bit 2390 This bit describes the handling of Type-7 LSAs, as specified in 2391 [Ref8]. 2393 R-bit 2394 This bit (the `Router' bit) indicates whether the originator is 2395 an active router. If the router bit is clear routes which 2396 transit the advertising node cannot be computed. Clearing the 2397 router bit would be appropriate for a multi-homed host that 2398 wants to participate in routing, but does not want to forward 2399 non-locally addressed packets. 2401 DC-bit 2402 This bit describes the router's handling of demand circuits, as 2403 specified in [Ref10]. 2405 A.3 OSPF Packet Formats 2407 There are five distinct OSPF packet types. All OSPF packet types 2408 begin with a standard 16 byte header. This header is described 2409 first. Each packet type is then described in a succeeding section. 2410 In these sections each packet's division into fields is displayed, 2411 and then the field definitions are enumerated. 2413 All OSPF packet types (other than the OSPF Hello packets) deal with 2414 lists of LSAs. For example, Link State Update packets implement the 2415 flooding of LSAs throughout the OSPF routing domain. The format of 2416 LSAs is described in Section A.4. 2418 The receive processing of OSPF packets is detailed in Section 3.2.2. 2419 The sending of OSPF packets is explained in Section 3.2.1. 2421 A.3.1 The OSPF packet header 2423 Every OSPF packet starts with a standard 16 byte header. Together 2424 with the encapsulating IPv6 headers, the OSPF header contains all 2425 the information necessary to determine whether the packet should be 2426 accepted for further processing. This determination is described in 2427 Section 3.2.2 of this memo. 2429 0 1 2 3 2430 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 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | Version # | Type | Packet length | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | Router ID | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | Area ID | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | Checksum | Instance ID | 0 | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 Version # 2442 The OSPF version number. This specification documents version 3 2443 of the OSPF protocol. 2445 Type 2446 The OSPF packet types are as follows. See Sections A.3.2 through 2447 A.3.6 for details. 2449 Type Description 2450 --------------------------------- 2451 1 Hello 2452 2 Database Description 2453 3 Link State Request 2454 4 Link State Update 2455 5 Link State Acknowledgment 2457 Packet length 2458 The length of the OSPF protocol packet in bytes. This length 2459 includes the standard OSPF header. 2461 Router ID 2462 The Router ID of the packet's source. 2464 Area ID 2465 A 32 bit number identifying the area that this packet belongs 2466 to. All OSPF packets are associated with a single area. Most 2467 travel a single hop only. Packets travelling over a virtual 2468 link are labelled with the backbone Area ID of 0. 2470 Checksum 2471 OSPF uses the standard checksum calculation for IPv6 2472 applications: The 16-bit one's complement of the one's 2473 complement sum of the entire contents of the packet, starting 2474 with the OSPF packet header, and prepending a "pseudo-header" of 2475 IPv6 header fields, as specified in [Ref14, section 8.1]. The 2476 "Upper-Layer Packet Length" in the pseudo-header is set to value 2477 of the OSPF packet header's length field. The Next Header value 2478 used in the pseudo-header is 89. If the packet's length is not 2479 an integral number of 16-bit words, the packet is padded with a 2480 byte of zero before checksumming. Before computing the checksum, 2481 the checksum field in the OSPF packet header is set to 0. 2483 Instance ID 2484 Enables multiple instances of OSPF to be run over a single link. 2485 Each protocol instance would be assigned a separate Instance ID; 2486 the Instance ID has local link significance only. Received 2487 packets whose Instance ID is not equal to the receiving 2488 interface's Instance ID are discarded. 2490 0 These fields are reserved. They must be 0. 2492 A.3.2 The Hello packet 2494 Hello packets are OSPF packet type 1. These packets are sent 2495 periodically on all interfaces (including virtual links) in order to 2496 establish and maintain neighbor relationships. In addition, Hello 2497 Packets are multicast on those links having a multicast or broadcast 2498 capability, enabling dynamic discovery of neighboring routers. 2500 All routers connected to a common link must agree on certain 2501 parameters (HelloInterval and RouterDeadInterval). These parameters 2502 are included in Hello packets, so that differences can inhibit the 2503 forming of neighbor relationships. The Hello packet also contains 2504 fields used in Designated Router election (Designated Router ID and 2505 Backup Designated Router ID), and fields used to detect bi- 2506 directionality (the Router IDs of all neighbors whose Hellos have 2507 been recently received). 2509 0 1 2 3 2510 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 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | 3 | 1 | Packet length | 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 | Router ID | 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 | Area ID | 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 | Checksum | Instance ID | 0 | 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | Interface ID | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | Rtr Pri | Options | 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 | HelloInterval | RouterDeadInterval | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | Designated Router ID | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | Backup Designated Router ID | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 | Neighbor ID | 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | ... | 2534 Interface ID 2535 32-bit number uniquely identifying this interface among the 2536 collection of this router's interfaces. For example, in some 2537 implementations it may be possible to use the MIB-II IfIndex 2538 ([Ref3]). 2540 Rtr Pri 2541 This router's Router Priority. Used in (Backup) Designated 2542 Router election. If set to 0, the router will be ineligible to 2543 become (Backup) Designated Router. 2545 Options 2546 The optional capabilities supported by the router, as documented 2547 in Section A.2. 2549 HelloInterval 2550 The number of seconds between this router's Hello packets. 2552 RouterDeadInterval 2553 The number of seconds before declaring a silent router down. 2555 Designated Router ID 2556 The identity of the Designated Router for this network, in the 2557 view of the sending router. The Designated Router is identified 2558 by its Router ID. Set to 0.0.0.0 if there is no Designated 2559 Router. 2561 Backup Designated Router ID 2562 The identity of the Backup Designated Router for this network, 2563 in the view of the sending router. The Backup Designated Router 2564 is identified by its IP Router ID. Set to 0.0.0.0 if there is 2565 no Backup Designated Router. 2567 Neighbor ID 2568 The Router IDs of each router from whom valid Hello packets have 2569 been seen recently on the network. Recently means in the last 2570 RouterDeadInterval seconds. 2572 A.3.3 The Database Description packet 2574 Database Description packets are OSPF packet type 2. These packets 2575 are exchanged when an adjacency is being initialized. They describe 2576 the contents of the link-state database. Multiple packets may be 2577 used to describe the database. For this purpose a poll-response 2578 procedure is used. One of the routers is designated to be the 2579 master, the other the slave. The master sends Database Description 2580 packets (polls) which are acknowledged by Database Description 2581 packets sent by the slave (responses). The responses are linked to 2582 the polls via the packets' DD sequence numbers. 2584 0 1 2 3 2585 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 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 | 3 | 2 | Packet length | 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 | Router ID | 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 | Area ID | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 | Checksum | Instance ID | 0 | 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | 0 | Options | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 | Interface MTU | 0 |0|0|0|0|0|I|M|MS 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 | DD sequence number | 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | | 2602 +- -+ 2603 | | 2604 +- An LSA Header -+ 2605 | | 2606 +- -+ 2607 | | 2608 +- -+ 2609 | | 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | ... | 2613 The format of the Database Description packet is very similar to 2614 both the Link State Request and Link State Acknowledgment packets. 2615 The main part of all three is a list of items, each item describing 2616 a piece of the link-state database. The sending of Database 2617 Description Packets is documented in Section 10.8 of [Ref1]. The 2618 reception of Database Description packets is documented in Section 2619 10.6 of [Ref1]. 2621 Options 2622 The optional capabilities supported by the router, as documented 2623 in Section A.2. 2625 Interface MTU 2626 The size in bytes of the largest IPv6 datagram that can be sent 2627 out the associated interface, without fragmentation. The 2628 MTUs of common Internet link types can be found in Table 2629 7-1 of [Ref12]. Interface MTU should be set to 0 in Database 2630 Description packets sent over virtual links. 2632 I-bit 2633 The Init bit. When set to 1, this packet is the first in the 2634 sequence of Database Description Packets. 2636 M-bit 2637 The More bit. When set to 1, it indicates that more Database 2638 Description Packets are to follow. 2640 MS-bit 2641 The Master/Slave bit. When set to 1, it indicates that the 2642 router is the master during the Database Exchange process. 2643 Otherwise, the router is the slave. 2645 DD sequence number 2646 Used to sequence the collection of Database Description Packets. 2647 The initial value (indicated by the Init bit being set) should 2648 be unique. The DD sequence number then increments until the 2649 complete database description has been sent. 2651 The rest of the packet consists of a (possibly partial) list of the 2652 link-state database's pieces. Each LSA in the database is described 2653 by its LSA header. The LSA header is documented in Section A.4.1. 2654 It contains all the information required to uniquely identify both 2655 the LSA and the LSA's current instance. 2657 A.3.4 The Link State Request packet 2659 Link State Request packets are OSPF packet type 3. After exchanging 2660 Database Description packets with a neighboring router, a router may 2661 find that parts of its link-state database are out-of-date. The 2662 Link State Request packet is used to request the pieces of the 2663 neighbor's database that are more up-to-date. Multiple Link State 2664 Request packets may need to be used. 2666 A router that sends a Link State Request packet has in mind the 2667 precise instance of the database pieces it is requesting. Each 2668 instance is defined by its LS sequence number, LS checksum, and LS 2669 age, although these fields are not specified in the Link State 2670 Request Packet itself. The router may receive even more recent 2671 instances in response. 2673 The sending of Link State Request packets is documented in Section 2674 10.9 of [Ref1]. The reception of Link State Request packets is 2675 documented in Section 10.7 of [Ref1]. 2677 0 1 2 3 2678 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 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | 3 | 3 | Packet length | 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 | Router ID | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 | Area ID | 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 | Checksum | Instance ID | 0 | 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 | 0 | LS type | 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | Link State ID | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | Advertising Router | 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 | ... | 2696 Each LSA requested is specified by its LS type, Link State ID, and 2697 Advertising Router. This uniquely identifies the LSA, but not its 2698 instance. Link State Request packets are understood to be requests 2699 for the most recent instance (whatever that might be). 2701 A.3.5 The Link State Update packet 2703 Link State Update packets are OSPF packet type 4. These packets 2704 implement the flooding of LSAs. Each Link State Update packet 2705 carries a collection of LSAs one hop further from their origin. 2706 Several LSAs may be included in a single packet. 2708 Link State Update packets are multicast on those physical networks 2709 that support multicast/broadcast. In order to make the flooding 2710 procedure reliable, flooded LSAs are acknowledged in Link State 2711 Acknowledgment packets. If retransmission of certain LSAs is 2712 necessary, the retransmitted LSAs are always carried by unicast Link 2713 State Update packets. For more information on the reliable flooding 2714 of LSAs, consult Section 3.5. 2716 0 1 2 3 2717 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 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 | 3 | 4 | Packet length | 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 | Router ID | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | Area ID | 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | Checksum | Instance ID | 0 | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | # LSAs | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | | 2730 +- +-+ 2731 | LSAs | 2732 +- +-+ 2733 | ... | 2735 # LSAs 2736 The number of LSAs included in this update. 2738 The body of the Link State Update packet consists of a list of LSAs. 2739 Each LSA begins with a common 20 byte header, described in Section 2740 A.4.2. Detailed formats of the different types of LSAs are described 2741 in Section A.4. 2743 A.3.6 The Link State Acknowledgment packet 2745 Link State Acknowledgment Packets are OSPF packet type 5. To make 2746 the flooding of LSAs reliable, flooded LSAs are explicitly 2747 acknowledged. This acknowledgment is accomplished through the 2748 sending and receiving of Link State Acknowledgment packets. The 2749 sending of Link State Acknowledgement packets is documented in 2750 Section 13.5 of [Ref1]. The reception of Link State Acknowledgement 2751 packets is documented in Section 13.7 of [Ref1]. 2753 Multiple LSAs can be acknowledged in a single Link State 2754 Acknowledgment packet. Depending on the state of the sending 2755 interface and the sender of the corresponding Link State Update 2756 packet, a Link State Acknowledgment packet is sent either to the 2757 multicast address AllSPFRouters, to the multicast address 2758 AllDRouters, or as a unicast (see Section 13.5 of [Ref1] for 2759 details). 2761 The format of this packet is similar to that of the Data Description 2762 packet. The body of both packets is simply a list of LSA headers. 2764 0 1 2 3 2765 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 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2767 | 3 | 5 | Packet length | 2768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2769 | Router ID | 2770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 | Area ID | 2772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2773 | Checksum | Instance ID | 0 | 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 | | 2776 +- -+ 2777 | | 2778 +- An LSA Header -+ 2779 | | 2780 +- -+ 2781 | | 2782 +- -+ 2783 | | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | ... | 2787 Each acknowledged LSA is described by its LSA header. The LSA 2788 header is documented in Section A.4.2. It contains all the 2789 information required to uniquely identify both the LSA and the LSA's 2790 current instance. 2792 A.4 LSA formats 2794 This memo defines seven distinct types of LSAs. Each LSA begins 2795 with a standard 20 byte LSA header. This header is explained in 2796 Section A.4.2. Succeeding sections then diagram the separate LSA 2797 types. 2799 Each LSA describes a piece of the OSPF routing domain. Every router 2800 originates a router-LSA. A network-LSA is advertised for each link 2801 by its Designated Router. A router's link-local addresses are 2802 advertised to its neighbors in link-LSAs. IPv6 prefixes are 2803 advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs and AS- 2804 external-LSAs. Location of specific routers can be advertised 2805 across area boundaries in inter-area-router-LSAs. All LSAs are then 2806 flooded throughout the OSPF routing domain. The flooding algorithm 2807 is reliable, ensuring that all routers have the same collection of 2808 LSAs. (See Section 3.5 for more information concerning the flooding 2809 algorithm). This collection of LSAs is called the link-state 2810 database. 2812 From the link state database, each router constructs a shortest path 2813 tree with itself as root. This yields a routing table (see Section 2814 11 of [Ref1]). For the details of the routing table build process, 2815 see Section 3.8. 2817 A.4.1 IPv6 Prefix Representation 2819 IPv6 addresses are bit strings of length 128. IPv6 routing 2820 algorithms, and OSPF for IPv6 in particular, advertise IPv6 address 2821 prefixes. IPv6 address prefixes are bit strings whose length ranges 2822 between 0 and 128 bits (inclusive). 2824 Within OSPF, IPv6 address prefixes are always represented by a 2825 combination of three fields: PrefixLength, PrefixOptions, and 2826 Address Prefix. PrefixLength is the length in bits of the prefix. 2827 PrefixOptions is an 8-bit field describing various capabilities 2828 associated with the prefix (see Section A.4.2). Address Prefix is an 2829 encoding of the prefix itself as an even multiple of 32-bit words, 2830 padding with zero bits as necessary; this encoding consumes 2831 (PrefixLength + 31) / 32) 32-bit words. 2833 The default route is represented by a prefix of length 0. 2835 Examples of IPv6 Prefix representation in OSPF can be found in 2836 Sections A.4.5, A.4.7, A.4.8 and A.4.9. 2838 A.4.1.1 Prefix Options 2840 Each prefix is advertised along with an 8-bit field of capabilities. 2841 These serve as input to the various routing calculations, allowing, 2842 for example, certain prefixes to be ignored in some cases, or to be 2843 marked as not readvertisable in others. 2845 0 1 2 3 4 5 6 7 2846 +--+--+--+--+--+--+--+--+ 2847 | | | | | P|MC|LA|NU| 2848 +--+--+--+--+--+--+--+--+ 2850 The Prefix Options field 2852 NU-bit 2853 The "no unicast" capability bit. If set, the prefix should be 2854 excluded from IPv6 unicast calculations, otherwise it should be 2855 included. 2857 LA-bit 2858 The "local address" capability bit. If set, the prefix is 2859 actually an IPv6 interface address of the advertising router. 2861 MC-bit 2862 The "multicast" capability bit. If set, the prefix should be 2863 included in IPv6 multicast routing calculations, otherwise it 2864 should be excluded. 2866 P-bit 2867 The "propagate" bit. Set on NSSA area prefixes that should be 2868 readvertised at the NSSA area border. 2870 A.4.2 The LSA header 2872 All LSAs begin with a common 20 byte header. This header contains 2873 enough information to uniquely identify the LSA (LS type, Link State 2874 ID, and Advertising Router). Multiple instances of the LSA may 2875 exist in the routing domain at the same time. It is then necessary 2876 to determine which instance is more recent. This is accomplished by 2877 examining the LS age, LS sequence number and LS checksum fields that 2878 are also contained in the LSA header. 2880 0 1 2 3 2881 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 2882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2883 | LS age | LS type | 2884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2885 | Link State ID | 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 | Advertising Router | 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 | LS sequence number | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | LS checksum | length | 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2894 LS age 2895 The time in seconds since the LSA was originated. 2897 LS type 2898 The LS type field indicates the function performed by the LSA. 2899 The high-order three bits of LS type encode generic properties 2900 of the LSA, while the remainder (called LSA function code) 2901 indicate the LSA's specific functionality. See Section A.4.2.1 2902 for a detailed description of LS type. 2904 Link State ID 2905 Together with LS type and Advertising Router, uniquely 2906 identifies the LSA in the link-state database. 2908 Advertising Router 2909 The Router ID of the router that originated the LSA. For 2910 example, in network-LSAs this field is equal to the Router ID of 2911 the network's Designated Router. 2913 LS sequence number 2914 Detects old or duplicate LSAs. Successive instances of an LSA 2915 are given successive LS sequence numbers. See Section 12.1.6 in 2916 [Ref1] for more details. 2918 LS checksum 2919 The Fletcher checksum of the complete contents of the LSA, 2920 including the LSA header but excluding the LS age field. See 2921 Section 12.1.7 in [Ref1] for more details. 2923 length 2924 The length in bytes of the LSA. This includes the 20 byte LSA 2925 header. 2927 A.4.2.1 LS type 2929 The LS type field indicates the function performed by the LSA. The 2930 high-order three bits of LS type encode generic properties of the 2931 LSA, while the remainder (called LSA function code) indicate the 2932 LSA's specific functionality. The format of the LS type is as 2933 follows: 2935 1 2936 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2937 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2938 |U |S2|S1| LSA Function Code | 2939 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2941 The U bit indicates how the LSA should be handled by a router which 2942 does not recognize the LSA's function code. Its values are: 2944 U-bit LSA Handling 2945 ------------------------------------------------------------- 2946 0 Treat the LSA as if it had link-local flooding scope 2947 1 Store and flood the LSA, as if type understood 2949 The S1 and S2 bits indicate the flooding scope of the LSA. The 2950 values are: 2952 S2 S1 Flooding Scope 2953 ------------------------------------------------------------------------ 2954 0 0 Link-Local Scoping. Flooded only on link it is originated on. 2955 0 1 Area Scoping. Flooded to all routers in the originating area 2956 1 0 AS Scoping. Flooded to all routers in the AS 2957 1 1 Reserved 2959 The LSA function codes are defined as follows. The origination and 2960 processing of these LSA function codes are defined elsewhere in this 2961 memo, except for the group-membership-LSA (see [Ref7]) and the 2962 Type-7-LSA (see [Ref8]). Each LSA function code also implies a 2963 specific setting for the U, S1 and S2 bits, as shown below. 2965 LSA function code LS Type Description 2966 ---------------------------------------------------- 2967 1 0x2001 Router-LSA 2968 2 0x2002 Network-LSA 2969 3 0x2003 Inter-Area-Prefix-LSA 2970 4 0x2004 Inter-Area-Router-LSA 2971 5 0x4005 AS-External-LSA 2972 6 0x2006 Group-membership-LSA 2973 7 0x2007 Type-7-LSA 2974 8 0x0008 Link-LSA 2975 9 0x2009 Intra-Area-Prefix-LSA 2976 A.4.3 Router-LSAs 2978 Router-LSAs have LS type equal to 0x2001. Each router in an area 2979 originates one or more router-LSAs. The complete collection of 2980 router-LSAs originated by the router describe the state and cost of 2981 the router's interfaces to the area. For details concerning the 2982 construction of router-LSAs, see Section 3.4.3.1. Router-LSAs are 2983 flooded throughout a single area only. 2985 0 1 2 3 2986 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 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2988 | LS age |0|0|1| 1 | 2989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 | Link State ID | 2991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2992 | Advertising Router | 2993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2994 | LS sequence number | 2995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2996 | LS checksum | length | 2997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2998 | 0 |W|V|E|B| Options | 2999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3000 | Type | 0 | Metric | 3001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3002 | Interface ID | 3003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3004 | Neighbor Interface ID | 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 | Neighbor Router ID | 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 | ... | 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 | Type | 0 | Metric | 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 | Interface ID | 3013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3014 | Neighbor Interface ID | 3015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3016 | Neighbor Router ID | 3017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3018 | ... | 3020 A single router may originate one or more Router LSAs, distinguished 3021 by their Link-State IDs (which are chosen arbitrarily by the 3022 originating router). The Options field and V, E and B bits should 3023 be the same in all Router LSAs from a single originator. However, 3024 in the case of a mismatch the values in the LSA with the lowest Link 3025 State ID take precedence. When more than one Router LSA is received 3026 from a single router, the links are processed as if concatenated 3027 into a single LSA. 3029 bit V 3030 When set, the router is an endpoint of one or more fully 3031 adjacent virtual links having the described area as Transit area 3032 (V is for virtual link endpoint). 3034 bit E 3035 When set, the router is an AS boundary router (E is for 3036 external). 3038 bit B 3039 When set, the router is an area border router (B is for border). 3041 bit W 3042 When set, the router is a wild-card multicast receiver. When 3043 running MOSPF, these routers receive all multicast datagrams, 3044 regardless of destination. See Sections 3, 4 and A.2 of [Ref8] 3045 for details. 3047 Options 3048 The optional capabilities supported by the router, as documented 3049 in Section A.2. 3051 The following fields are used to describe each router interface. 3052 The Type field indicates the kind of interface being described. It 3053 may be an interface to a transit network, a point-to-point 3054 connection to another router or a virtual link. The values of all 3055 the other fields describing a router interface depend on the 3056 interface's Type field. 3058 Type 3059 The kind of interface being described. One of the following: 3061 Type Description 3062 --------------------------------------------------- 3063 1 Point-to-point connection to another router 3064 2 Connection to a transit network 3065 3 Reserved 3066 4 Virtual link 3068 Metric 3069 The cost of using this router interface, for outbound traffic. 3071 Interface ID 3072 The Interface ID assigned to the interface being described. See 3073 Sections 3.1.2 and C.3. 3075 Neighbor Interface ID 3076 The Interface ID the neighbor router (or the attached link's 3077 Designated Router, for Type 2 interfaces) has been advertising 3078 in hello packets sent on the attached link. 3080 Neighbor Router ID 3081 The Router ID the neighbor router (or the attached link's 3082 Designated Router, for Type 2 interfaces). 3084 For Type 2 links, the combination of Neighbor Interface ID and 3085 Neighbor Router ID allows the network-LSA for the attached link 3086 to be found in the link-state database. 3088 A.4.4 Network-LSAs 3090 Network-LSAs have LS type equal to 0x2002. A network-LSA is 3091 originated for each broadcast and NBMA link in the area which 3092 supports two or more routers. The network-LSA is originated by the 3093 link's Designated Router. The LSA describes all routers attached to 3094 the link, including the Designated Router itself. The LSA's Link 3095 State ID field is set to the Interface ID that the Designated Router 3096 has been advertising in Hello packets on the link. 3098 The distance from the network to all attached routers is zero. This 3099 is why the metric fields need not be specified in the network-LSA. 3100 For details concerning the construction of network-LSAs, see Section 3101 3.4.3.2. 3103 0 1 2 3 3104 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 3105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3106 | LS age |0|0|1| 2 | 3107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3108 | Link State ID | 3109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3110 | Advertising Router | 3111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3112 | LS sequence number | 3113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3114 | LS checksum | length | 3115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3116 | 0 | Options | 3117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 | Attached Router | 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3120 | ... | 3122 Attached Router 3123 The Router IDs of each of the routers attached to the link. 3124 Actually, only those routers that are fully adjacent to the 3125 Designated Router are listed. The Designated Router includes 3126 itself in this list. The number of routers included can be 3127 deduced from the LSA header's length field. 3129 A.4.5 Inter-Area-Prefix-LSAs 3131 Inter-Area-Prefix-LSAs have LS type equal to 0x2003. These LSAs are 3132 are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see 3133 Section 12.4.3 of [Ref1]). Originated by area border routers, they 3134 describe routes to IPv6 address prefixes that belong to other areas. 3135 A separate Inter-Area-Prefix-LSA is originated for each IPv6 address 3136 prefix. For details concerning the construction of Inter-Area- 3137 Prefix-LSAs, see Section 3.4.3.3. 3139 For stub areas, Inter-Area-Prefix-LSAs can also be used to describe 3140 a (per-area) default route. Default summary routes are used in stub 3141 areas instead of flooding a complete set of external routes. When 3142 describing a default summary route, the Inter-Area-Prefix-LSA's 3143 PrefixLength is set to 0. 3145 0 1 2 3 3146 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 3147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3148 | LS age |0|0|1| 3 | 3149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3150 | Link State ID | 3151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3152 | Advertising Router | 3153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3154 | LS sequence number | 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 | LS checksum | length | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | 0 | Metric | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 | PrefixLength | PrefixOptions | (0) | 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3162 | Address Prefix | 3163 | ... | 3164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 Metric 3167 The cost of this route. Expressed in the same units as the 3168 interface costs in the router-LSAs. When the Inter-Area-Prefix- 3169 LSA is describing a route to a range of addresses (see Section 3170 C.2) the cost is set to the maximum cost to any reachable 3171 component of the address range. 3173 PrefixLength, PrefixOptions and Address Prefix 3174 Representation of the IPv6 address prefix, as described in 3175 Section A.4.1. 3177 A.4.6 Inter-Area-Router-LSAs 3179 Inter-Area-Router-LSAs have LS type equal to 0x2004. These LSAs are 3180 are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see 3181 Section 12.4.3 of [Ref1]). Originated by area border routers, they 3182 describe routes to routers in other areas. (To see why it is 3183 necessary to advertise the location of each ASBR, consult Section 3184 16.4 in [Ref1].) Each LSA describes a route to a single router. For 3185 details concerning the construction of Inter-Area-Router-LSAs, see 3186 Section 3.4.3.4. 3188 0 1 2 3 3189 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 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 | LS age |0|0|1| 4 | 3192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3193 | Link State ID | 3194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3195 | Advertising Router | 3196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3197 | LS sequence number | 3198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3199 | LS checksum | length | 3200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3201 | 0 | Options | 3202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3203 | 0 | Metric | 3204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3205 | Destination Router ID | 3206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 Options 3209 The optional capabilities supported by the router, as documented 3210 in Section A.2. 3212 Metric 3213 The cost of this route. Expressed in the same units as the 3214 interface costs in the router-LSAs. 3216 Destination Router ID 3217 The Router ID of the router being described by the LSA. 3219 A.4.7 AS-external-LSAs 3221 AS-external-LSAs have LS type equal to 0x4005. These LSAs are 3222 originated by AS boundary routers, and describe destinations 3223 external to the AS. Each LSA describes a route to a single IPv6 3224 address prefix. For details concerning the construction of AS- 3225 external-LSAs, see Section 3.4.3.5. 3227 AS-external-LSAs can be used to describe a default route. Default 3228 routes are used when no specific route exists to the destination. 3229 When describing a default route, the AS-external-LSA's PrefixLength 3230 is set to 0. 3232 0 1 2 3 3233 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 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3235 | LS age |0|1|0| 5 | 3236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3237 | Link State ID | 3238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3239 | Advertising Router | 3240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3241 | LS sequence number | 3242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3243 | LS checksum | length | 3244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3245 | |E|F|T| Metric | 3246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3247 | PrefixLength | PrefixOptions | Referenced LS Type | 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 | Address Prefix | 3250 | ... | 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 | | 3253 +- -+ 3254 | | 3255 +- Forwarding Address (Optional) -+ 3256 | | 3257 +- -+ 3258 | | 3259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3260 | External Route Tag (Optional) | 3261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3262 | Referenced Link State ID (Optional) | 3263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 bit E 3266 The type of external metric. If bit E is set, the metric 3267 specified is a Type 2 external metric. This means the metric is 3268 considered larger than any intra-AS path. If bit E is zero, the 3269 specified metric is a Type 1 external metric. This means that 3270 it is expressed in the same units as the link state metric 3271 (i.e., the same units as interface cost). 3273 bit F 3274 If set, a Forwarding Address has been included in the LSA. 3276 bit T 3277 If set, an External Route Tag has been included in the LSA. 3279 Metric 3280 The cost of this route. Interpretation depends on the external 3281 type indication (bit E above). 3283 PrefixLength, PrefixOptions and Address Prefix 3284 Representation of the IPv6 address prefix, as described in 3285 Section A.4.1. 3287 Referenced LS type 3288 If non-zero, an LSA with this LS type is to be associated with 3289 this LSA (see Referenced Link State ID below). 3291 Forwarding address 3292 A fully qualified IPv6 address (128 bits). Included in the LSA 3293 if and only if bit F has been set. If included, Data traffic 3294 for the advertised destination will be forwarded to this 3295 address. Must not be set to the IPv6 Unspecified Address 3296 (0:0:0:0:0:0:0:0). 3298 External Route Tag 3299 A 32-bit field which may be used to communicate additional 3300 information between AS boundary routers; see [Ref5] for example 3301 usage. Included in the LSA if and only if bit T has been set. 3303 Referenced Link State ID 3304 Included if and only if Reference LS Type is non-zero. If 3305 included, additional information concerning the advertised 3306 external route can be found in the LSA having LS type equal to 3307 "Referenced LS Type", Link State ID equal to "Referenced Link 3308 State ID" and Advertising Router the same as that specified in 3309 the AS-external-LSA's link state header. This additional 3310 information is not used by the OSPF protocol itself. It may be 3311 used to communicate information between AS boundary routers; the 3312 precise nature of such information is outside the scope of this 3313 specification. 3315 All, none or some of the fields labeled Forwarding address, External 3316 Route Tag and Referenced Link State ID may be present in the AS- 3317 external-LSA (as indicated by the setting of bit F, bit T and 3318 Referenced LS type respectively). However, when present Forwarding 3319 Address always comes first, with External Route Tag always preceding 3320 Referenced Link State ID. 3322 A.4.8 Link-LSAs 3324 Link-LSAs have LS type equal to 0x0008. A router originates a 3325 separate Link-LSA for each link it is attached to. These LSAs have 3326 local-link flooding scope; they are never flooded beyond the link 3327 that they are associated with. Link-LSAs have three purposes: 1) 3328 they provide the router's link-local address to all other routers 3329 attached to the link and 2) they inform other routers attached to 3330 the link of a list of IPv6 prefixes to associate with the link and 3331 3) they allow the router to assert a collection of Options bits to 3332 associate with the Network-LSA that will be originated for the link. 3334 A link-LSA's Link State ID is set equal to the originating router's 3335 Interface ID on the link. 3336 0 1 2 3 3337 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 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3339 | LS age |0|0|0| 8 | 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 | Link State ID | 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | Advertising Router | 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | LS sequence number | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | LS checksum | length | 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3349 | Rtr Pri | Options | 3350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 | | 3352 +- -+ 3353 | | 3354 +- Link-local Interface Address -+ 3355 | | 3356 +- -+ 3357 | | 3358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3359 | # prefixes | 3360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 | PrefixLength | PrefixOptions | (0) | 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 | Address Prefix | 3364 | ... | 3365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3366 | ... | 3367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 | PrefixLength | PrefixOptions | (0) | 3369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3370 | Address Prefix | 3371 | ... | 3372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3374 Rtr Pri 3375 The Router Priority of the interface attaching the originating 3376 router to the link. 3378 Options 3379 The set of Options bits that the router would like set in the 3380 Network-LSA that will be originated for the link. 3382 Link-local Interface Address 3383 The originating router's link-local interface address on the 3384 link. 3386 # prefixes 3387 The number of IPv6 address prefixes contained in the LSA. 3389 The rest of the link-LSA contains a list of IPv6 prefixes to be 3390 associated with the link. 3392 PrefixLength, PrefixOptions and Address Prefix 3393 Representation of an IPv6 address prefix, as described in 3394 Section A.4.1. 3396 A.4.9 Intra-Area-Prefix-LSAs 3398 Intra-Area-Prefix-LSAs have LS type equal to 0x2009. A router uses 3399 Intra-Area-Prefix-LSAs to advertise one or more IPv6 address 3400 prefixes that are associated with a) the router itself, b) an 3401 attached stub network segment or c) an attached transit network 3402 segment. In IPv4, a) and b) were accomplished via the router's 3403 router-LSA, and c) via a network-LSA. However, in OSPF for IPv6 all 3404 addressing information has been removed from router-LSAs and 3405 network-LSAs, leading to the introduction of the Intra-Area-Prefix- 3406 LSA. 3408 A router can originate multiple Intra-Area-Prefix-LSAs for each 3409 router or transit network; each such LSA is distinguished by its 3410 Link State ID. 3412 0 1 2 3 3413 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 3414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3415 | LS age |0|0|1| 9 | 3416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3417 | Link State ID | 3418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3419 | Advertising Router | 3420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3421 | LS sequence number | 3422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3423 | LS checksum | length | 3424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3425 | # prefixes | Referenced LS type | 3426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3427 | Referenced Link State ID | 3428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3429 | Referenced Advertising Router | 3430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3431 | PrefixLength | PrefixOptions | Metric | 3432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3433 | Address Prefix | 3434 | ... | 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 | ... | 3437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3438 | PrefixLength | PrefixOptions | Metric | 3439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3440 | Address Prefix | 3441 | ... | 3442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3444 # prefixes 3445 The number of IPv6 address prefixes contained in the LSA. 3447 Router 3448 Referenced LS type, Referenced Link State ID and Referenced 3449 Advertising 3450 Identifies the router-LSA or network-LSA with which the IPv6 3451 address prefixes should be associated. If Referenced LS type is 3452 1, the prefixes are associated with a router-LSA, Referenced 3453 Link State ID should be 0 and Referenced Advertising Router 3454 should be the originating router's Router ID. If Referenced LS 3455 type is 2, the prefixes are associated with a network-LSA, 3456 Referenced Link State ID should be the Interface ID of the 3457 link's Designated Router and Referenced Advertising Router 3458 should be the Designated Router's Router ID. 3460 The rest of the Intra-Area-Prefix-LSA contains a list of IPv6 3461 prefixes to be associated with the router or transit link, together 3462 with the cost of each prefix. 3464 PrefixLength, PrefixOptions and Address Prefix 3465 Representation of an IPv6 address prefix, as described in 3466 Section A.4.1. 3468 Metric 3469 The cost of this prefix. Expressed in the same units as the 3470 interface costs in the router-LSAs. 3472 B. Architectural Constants 3474 Architectural constants for the OSPF protocol are defined in 3475 Appendix B of [Ref1]. The only difference for OSPF for IPv6 is that 3476 DefaultDestination is encoded as a prefix of length 0 (see Section 3477 A.4.1). 3479 C. Configurable Constants 3481 The OSPF protocol has quite a few configurable parameters. These 3482 parameters are listed below. They are grouped into general 3483 functional categories (area parameters, interface parameters, etc.). 3484 Sample values are given for some of the parameters. 3486 Some parameter settings need to be consistent among groups of 3487 routers. For example, all routers in an area must agree on that 3488 area's parameters, and all routers attached to a network must agree 3489 on that network's HelloInterval and RouterDeadInterval. 3491 Some parameters may be determined by router algorithms outside of 3492 this specification (e.g., the address of a host connected to the 3493 router via a SLIP line). From OSPF's point of view, these items are 3494 still configurable. 3496 C.1 Global parameters 3498 In general, a separate copy of the OSPF protocol is run for each 3499 area. Because of this, most configuration parameters are 3500 defined on a per-area basis. The few global configuration 3501 parameters are listed below. 3503 Router ID 3504 This is a 32-bit number that uniquely identifies the router 3505 in the Autonomous System. If a router's OSPF Router ID is 3506 changed, the router's OSPF software should be restarted 3507 before the new Router ID takes effect. Before restarting in 3508 order to change its Router ID, the router should flush its 3509 self-originated LSAs from the routing domain (see Section 3510 14.1 of [Ref1]), or they will persist for up to MaxAge 3511 minutes. 3513 Because the size of the Router ID is smaller than an IPv6 3514 address, it cannot be set to one of the router's IPv6 3515 addresses (as is commonly done for IPv4). Possible Router ID 3516 assignment procedures for IPv6 include: a) assign the IPv6 3517 Router ID as one of the router's IPv4 addresses or b) assign 3518 IPv6 Router IDs through some local administrative procedure 3519 (similar to procedures used by manufacturers to assign 3520 product serial numbers). 3522 The Router ID of 0.0.0.0 is reserved, and should not be 3523 used. 3525 C.2 Area parameters 3527 All routers belonging to an area must agree on that area's 3528 configuration. Disagreements between two routers will lead to 3529 an inability for adjacencies to form between them, with a 3530 resulting hindrance to the flow of routing protocol and data 3531 traffic. The following items must be configured for an area: 3533 Area ID 3534 This is a 32-bit number that identifies the area. The Area 3535 ID of 0 is reserved for the backbone. 3537 List of address ranges 3538 Address ranges control the advertisement of routes across 3539 area boundaries. Each address range consists of the 3540 following items: 3542 [IPv6 prefix, prefix length] 3543 Describes the collection of IPv6 addresses contained 3544 in the address range. 3546 Status Set to either Advertise or DoNotAdvertise. Routing 3547 information is condensed at area boundaries. 3548 External to the area, at most a single route is 3549 advertised (via a inter-area-prefix-LSA) for each 3550 address range. The route is advertised if and only 3551 if the address range's Status is set to Advertise. 3552 Unadvertised ranges allow the existence of certain 3553 networks to be intentionally hidden from other 3554 areas. Status is set to Advertise by default. 3556 ExternalRoutingCapability 3557 Whether AS-external-LSAs will be flooded into/throughout the 3558 area. If AS-external-LSAs are excluded from the area, the 3559 area is called a "stub". Internal to stub areas, routing to 3560 external destinations will be based solely on a default 3561 inter-area route. The backbone cannot be configured as a 3562 stub area. Also, virtual links cannot be configured through 3563 stub areas. For more information, see Section 3.6 of 3564 [Ref1]. 3566 StubDefaultCost 3567 If the area has been configured as a stub area, and the 3568 router itself is an area border router, then the 3569 StubDefaultCost indicates the cost of the default inter- 3570 area-prefix-LSA that the router should advertise into the 3571 area. See Section 12.4.3.1 of [Ref1] for more information. 3573 C.3 Router interface parameters 3575 Some of the configurable router interface parameters (such as 3576 Area ID, HelloInterval and RouterDeadInterval) actually imply 3577 properties of the attached links, and therefore must be 3578 consistent across all the routers attached to that link. The 3579 parameters that must be configured for a router interface are: 3581 IPv6 link-local address 3582 The IPv6 link-local address associated with this interface. 3583 May be learned through auto-configuration. 3585 Area ID 3586 The OSPF area to which the attached link belongs. 3588 Instance ID 3589 The OSPF protocol instance associated with this OSPF 3590 interface. Defaults to 0. 3592 Interface ID 3593 32-bit number uniquely identifying this interface among the 3594 collection of this router's interfaces. For example, in some 3595 implementations it may be possible to use the MIB-II IfIndex 3596 ([Ref3]). 3598 IPv6 prefixes 3599 The list of IPv6 prefixes to associate with the link. These 3600 will be advertised in intra-area-prefix-LSAs. 3602 Interface output cost(s) 3603 The cost of sending a packet on the interface, expressed in 3604 the link state metric. This is advertised as the link cost 3605 for this interface in the router's router-LSA. The interface 3606 output cost must always be greater than 0. 3608 RxmtInterval 3609 The number of seconds between LSA retransmissions, for 3610 adjacencies belonging to this interface. Also used when 3611 retransmitting Database Description and Link State Request 3612 Packets. This should be well over the expected round-trip 3613 delay between any two routers on the attached link. The 3614 setting of this value should be conservative or needless 3615 retransmissions will result. Sample value for a local area 3616 network: 5 seconds. 3618 InfTransDelay 3619 The estimated number of seconds it takes to transmit a Link 3620 State Update Packet over this interface. LSAs contained in 3621 the update packet must have their age incremented by this 3622 amount before transmission. This value should take into 3623 account the transmission and propagation delays of the 3624 interface. It must be greater than 0. Sample value for a 3625 local area network: 1 second. 3627 Router Priority 3628 An 8-bit unsigned integer. When two routers attached to a 3629 network both attempt to become Designated Router, the one 3630 with the highest Router Priority takes precedence. If there 3631 is still a tie, the router with the highest Router ID takes 3632 precedence. A router whose Router Priority is set to 0 is 3633 ineligible to become Designated Router on the attached link. 3634 Router Priority is only configured for interfaces to 3635 broadcast and NBMA networks. 3637 HelloInterval 3638 The length of time, in seconds, between the Hello Packets 3639 that the router sends on the interface. This value is 3640 advertised in the router's Hello Packets. It must be the 3641 same for all routers attached to a common link. The smaller 3642 the HelloInterval, the faster topological changes will be 3643 detected; however, more OSPF routing protocol traffic will 3644 ensue. Sample value for a X.25 PDN: 30 seconds. Sample 3645 value for a local area network (LAN): 10 seconds. 3647 RouterDeadInterval 3648 After ceasing to hear a router's Hello Packets, the number 3649 of seconds before its neighbors declare the router down. 3650 This is also advertised in the router's Hello Packets in 3651 their RouterDeadInterval field. This should be some 3652 multiple of the HelloInterval (say 4). This value again 3653 must be the same for all routers attached to a common link. 3655 C.4 Virtual link parameters 3657 Virtual links are used to restore/increase connectivity of the 3658 backbone. Virtual links may be configured between any pair of 3659 area border routers having interfaces to a common (non-backbone) 3660 area. The virtual link appears as an unnumbered point-to-point 3661 link in the graph for the backbone. The virtual link must be 3662 configured in both of the area border routers. 3664 A virtual link appears in router-LSAs (for the backbone) as if 3665 it were a separate router interface to the backbone. As such, 3666 it has most of the parameters associated with a router interface 3667 (see Section C.3). Virtual links do not have link-local 3668 addresses, but instead use one of the router's global-scope or 3669 site-local IPv6 addresses as the IP source in OSPF protocol 3670 packets it sends along the virtual link. Router Priority is not 3671 used on virtual links. Interface output cost is not configured 3672 on virtual links, but is dynamically set to be the cost of the 3673 intra-area path between the two endpoint routers. The parameter 3674 RxmtInterval must be configured, and should be well over the 3675 expected round-trip delay between the two routers. This may be 3676 hard to estimate for a virtual link; it is better to err on the 3677 side of making it too large. 3679 A virtual link is defined by the following two configurable 3680 parameters: the Router ID of the virtual link's other endpoint, 3681 and the (non-backbone) area through which the virtual link runs 3682 (referred to as the virtual link's Transit area). Virtual links 3683 cannot be configured through stub areas. 3685 C.5 NBMA network parameters 3687 OSPF treats an NBMA network much like it treats a broadcast 3688 network. Since there may be many routers attached to the 3689 network, a Designated Router is selected for the network. This 3690 Designated Router then originates a network-LSA, which lists all 3691 routers attached to the NBMA network. 3693 However, due to the lack of broadcast capabilities, it may be 3694 necessary to use configuration parameters in the Designated 3695 Router selection. These parameters will only need to be 3696 configured in those routers that are themselves eligible to 3697 become Designated Router (i.e., those router's whose Router 3698 Priority for the network is non-zero), and then only if no 3699 automatic procedure for discovering neighbors exists: 3701 List of all other attached routers 3702 The list of all other routers attached to the NBMA network. 3703 Each router is configured with its Router ID and IPv6 link- 3704 local address on the network. Also, for each router listed, 3705 that router's eligibility to become Designated Router must 3706 be defined. When an interface to a NBMA network comes up, 3707 the router sends Hello Packets only to those neighbors 3708 eligible to become Designated Router, until the identity of 3709 the Designated Router is discovered. 3711 PollInterval 3712 If a neighboring router has become inactive (Hello Packets 3713 have not been seen for RouterDeadInterval seconds), it may 3714 still be necessary to send Hello Packets to the dead 3715 neighbor. These Hello Packets will be sent at the reduced 3716 rate PollInterval, which should be much larger than 3717 HelloInterval. Sample value for a PDN X.25 network: 2 3718 minutes. 3720 C.6 Point-to-MultiPoint network parameters 3722 On Point-to-MultiPoint networks, it may be necessary to 3723 configure the set of neighbors that are directly reachable over 3724 the Point-to-MultiPoint network. Each neighbor is configured 3725 with its Router ID and IPv6 link-local address on the network. 3726 Designated Routers are not elected on Point-to-MultiPoint 3727 networks, so the Designated Router eligibility of configured 3728 neighbors is undefined. 3730 C.7 Host route parameters 3732 Host prefixes are advertised in intra-area-prefix-LSAs. They 3733 indicate either internal router addresses, router interfaces to 3734 point-to-point networks, looped router interfaces, or IPv6 hosts 3735 that are directly connected to the router (e.g., via a PPP 3736 connection). For each host directly connected to the router, 3737 the following items must be configured: 3739 Host IPv6 prefix 3740 The IPv6 prefix belonging to the host. 3742 Cost of link to host 3743 The cost of sending a packet to the host, in terms of the 3744 link state metric. However, since the host probably has only 3745 a single connection to the internet, the actual configured 3746 cost(s) in many cases is unimportant (i.e., will have no 3747 effect on routing). 3749 Area ID 3750 The OSPF area to which the host's prefix belongs. 3752 Security Considerations 3754 When running over IPv6, OSPF relies on the IP Authentication Header 3755 (see [Ref19]) and the IP Encapsulating Security Payload (see 3756 [Ref20]) to ensure integrity and authentication/confidentiality of 3757 routing exchanges. 3759 Most OSPF implementations will be running on systems that support 3760 multiple protocols, many of them having independent security 3761 assumptions and domains. When IPSEC is used to protect OSPF 3762 packets, it is important for the implementation to check the IPSEC 3763 SA, and local SA database to make sure that the packet originates 3764 from a source THAT IS TRUSTED FOR OSPF PURPOSES. 3766 Authors Addresses 3768 Rob Coltun 3769 Siara Systems 3770 300 Ferguson Drive 3771 Mountain View, CA 94043 3772 Phone: (650) 390-9030 3773 Email: rcoltun@siara.com 3775 Dennis Ferguson 3776 Juniper Networks 3777 385 Ravendale Drive 3778 Mountain View, CA 94043 3779 Phone: +1 650 526 8004 3780 Email: dennis@juniper.com 3782 John Moy 3783 Sycamore Networks, Inc. 3784 10 Elizabeth Drive 3785 Chelmsford, MA 01824 3786 Phone: (978) 367-2161 3787 Fax: (978) 250-3350 3788 Email: jmoy@sycamorenet.com 3790 This document expires in April 2000.