idnits 2.17.1 draft-ietf-ospf-ospfv6-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 2704 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 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 (November 1997) is 9657 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 2177, but no explicit reference was found in the text == Unused Reference: 'Ref3' is defined on line 2180, but no explicit reference was found in the text == Unused Reference: 'Ref4' is defined on line 2185, but no explicit reference was found in the text == Unused Reference: 'Ref6' is defined on line 2193, but no explicit reference was found in the text == Unused Reference: 'Ref12' is defined on line 2596, but no explicit reference was found in the text == Unused Reference: 'Ref13' is defined on line 2215, but no explicit reference was found in the text == Unused Reference: 'Ref16' is defined on line 2227, but no explicit reference was found in the text == Unused Reference: 'Ref17' is defined on line 2232, but no explicit reference was found in the text == Unused Reference: 'Ref18' is defined on line 2235, 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') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref3' ** 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref12' ** Obsolete normative reference: RFC 1771 (ref. 'Ref13') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 1883 (ref. 'Ref14') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1884 (ref. 'Ref15') (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 1885 (ref. 'Ref16') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1970 (ref. 'Ref17') (Obsoleted by RFC 2461) ** Obsolete normative reference: RFC 1981 (ref. 'Ref18') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 1826 (ref. 'Ref19') (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref20' Summary: 24 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Coltun 3 Internet Draft FORE Systems 4 Expiration Date: May 1998 D. Ferguson 5 File name: draft-ietf-ospf-ospfv6-05.txt Juniper Networks 6 Network Working Group J. Moy 7 Internet Draft Ascend Communications Inc. 8 November 1997 10 OSPF for IPv6 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet- Drafts as 22 reference material or to cite them other than as "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This document describes the modifications to OSPF to support version 33 6 of the Internet Protocol (IPv6). The fundamental mechanisms of 34 OSPF (flooding, DR election, area support, SPF calculations, etc.) 35 remain unchanged. However, some changes have been necessary, either 36 due to changes in protocol semantics between IPv4 and IPv6, or 37 simply to handle the increased address size of IPv6. 39 Changes between OSPF for IPv4 and this document include the 40 following. Addressing semantics have been removed from OSPF packets 41 and the basic LSAs. New LSAs have been created to carry IPv6 42 addresses and prefixes. OSPF now runs on a per-link basis, instead 43 of on a per-IP-subnet basis. Flooding scope for LSAs has been 44 generalized. Authentication has been removed from the OSPF protocol 45 itself, instead relying on IPv6's Authentication Header and 46 Encapsulating Security Payload. 48 Most packets in OSPF for IPv6 are almost as compact as those in OSPF 49 for IPv4, even with the larger IPv6 addresses. Most field- and 50 packet-size limitations present in OSPF for IPv4 have been relaxed. 51 In addition, option handling has been made more flexible. 53 All of OSPF for IPv4's optional capabilities, including on-demand 54 circuit support, NSSA areas, and the multicast extensions to OSPF 55 (MOSPF) are also supported in OSPF for IPv6. 57 Please send comments to ospf@gated.cornell.edu. 59 Table of Contents 61 1 Introduction ........................................... 5 62 1.1 Terminology ............................................ 5 63 2 Differences from OSPF for IPv4 ......................... 5 64 2.1 Protocol processing per-link, not per-subnet ........... 5 65 2.2 Removal of addressing semantics ........................ 6 66 2.3 Addition of Flooding scope ............................. 6 67 2.4 Explicit support for multiple instances per link ....... 7 68 2.5 Use of link-local addresses ............................ 7 69 2.6 Authentication changes ................................. 8 70 2.7 Packet format changes .................................. 8 71 2.8 LSA format changes ..................................... 9 72 2.9 Handling unknown LSA types ............................ 11 73 2.10 Stub area support ..................................... 11 74 2.11 Identifying neighbors by Router ID .................... 12 75 3 Implementation details ................................ 12 76 3.1 Protocol data structures .............................. 13 77 3.1.1 The Area Data structure ............................... 14 78 3.1.2 The Interface Data structure .......................... 14 79 3.1.3 The Neighbor Data Structure ........................... 16 80 3.2 Protocol Packet Processing ............................ 16 81 3.2.1 Sending protocol packets .............................. 17 82 3.2.1.1 Sending Hello packets ................................. 18 83 3.2.1.2 Sending Database Description Packets .................. 18 84 3.2.2 Receiving protocol packets ............................ 19 85 3.2.2.1 Receiving Hello Packets ............................... 21 86 3.3 The Routing table Structure ........................... 21 87 3.3.1 Routing table lookup .................................. 22 88 3.4 Link State Advertisements ............................. 22 89 3.4.1 The LSA Header ........................................ 23 90 3.4.2 The link-state database ............................... 24 91 3.4.3 Originating LSAs ...................................... 24 92 3.4.3.1 Router-LSAs ........................................... 26 93 3.4.3.2 Network-LSAs .......................................... 29 94 3.4.3.3 Inter-Area-Prefix-LSAs ................................ 30 95 3.4.3.4 Inter-Area-Router-LSAs ................................ 31 96 3.4.3.5 AS-external-LSAs ...................................... 32 97 3.4.3.6 Link-LSAs ............................................. 33 98 3.4.3.7 Intra-Area-Prefix-LSAs ................................ 35 99 3.5 Flooding .............................................. 38 100 3.5.1 Receiving Link State Update packets ................... 38 101 3.5.2 Sending Link State Update packets ..................... 39 102 3.5.3 Installing LSAs in the database ....................... 41 103 3.6 Definition of self-originated LSAs .................... 42 104 3.7 Virtual links ......................................... 42 105 3.8 Routing table calculation ............................. 43 106 3.8.1 Calculating the shortest path tree for an area ........ 44 107 3.8.1.1 The next hop calculation .............................. 45 108 3.8.2 Calculating the inter-area routes ..................... 45 109 3.8.3 Examining transit areas' summary-LSAs ................. 46 110 3.8.4 Calculating AS external routes ........................ 46 111 3.9 Multiple interfaces to a single link .................. 46 112 References ............................................ 48 113 A OSPF data formats ..................................... 50 114 A.1 Encapsulation of OSPF packets ......................... 50 115 A.2 The Options field ..................................... 52 116 A.3 OSPF Packet Formats ................................... 54 117 A.3.1 The OSPF packet header ................................ 55 118 A.3.2 The Hello packet ...................................... 57 119 A.3.3 The Database Description packet ....................... 59 120 A.3.4 The Link State Request packet ......................... 61 121 A.3.5 The Link State Update packet .......................... 62 122 A.3.6 The Link State Acknowledgment packet .................. 63 123 A.4 LSA formats ........................................... 65 124 A.4.1 IPv6 Prefix Representation ............................ 66 125 A.4.1.1 Prefix Options ........................................ 67 126 A.4.2 The LSA header ........................................ 68 127 A.4.2.1 LS type ............................................... 70 128 A.4.3 Router-LSAs ........................................... 72 129 A.4.4 Network-LSAs .......................................... 75 130 A.4.5 Inter-Area-Prefix-LSAs ................................ 76 131 A.4.6 Inter-Area-Router-LSAs ................................ 78 132 A.4.7 AS-external-LSAs ...................................... 79 133 A.4.8 Link-LSAs ............................................. 82 134 A.4.9 Intra-Area-Prefix-LSAs ................................ 84 135 B Architectural Constants ............................... 86 136 C Configurable Constants ................................ 86 137 C.1 Global parameters ..................................... 86 138 C.2 Area parameters ....................................... 87 139 C.3 Router interface parameters ........................... 88 140 C.4 Virtual link parameters ............................... 89 141 C.5 NBMA network parameters ............................... 90 142 C.6 Point-to-MultiPoint network parameters ................ 91 143 C.7 Host route parameters ................................. 91 144 Security Considerations ............................... 92 145 Authors' Addresses .................................... 92 146 1. Introduction 148 This document describes the modifications to OSPF to support version 149 6 of the Internet Protocol (IPv6). The fundamental mechanisms of 150 OSPF (flooding, DR election, area support, SPF calculations, etc.) 151 remain unchanged. However, some changes have been necessary, either 152 due to changes in protocol semantics between IPv4 and IPv6, or 153 simply to handle the increased address size of IPv6. 155 This document is organized as follows. Section 2 describes the 156 differences between OSPF for IPv4 and OSPF for IPv6 in detail. 157 Section 3 provides implementation details for the changes. Appendix 158 A gives the OSPF for IPv6 packet and LSA formats. Appendix B lists 159 the OSPF architectural constants. Appendix C describes configuration 160 parameters. 162 1.1. Terminology 164 This document attempts to use terms from both the OSPF for IPv4 165 specification ([Ref1]) and the IPv6 protocol specifications 166 ([Ref14]). This has produced a mixed result. Most of the terms 167 used both by OSPF and IPv6 have roughly the same meaning (e.g., 168 interfaces). However, there are a few conflicts. IPv6 uses 169 "link" similarly to IPv4 OSPF's "subnet" or "network". In this 170 case, we have chosen to use IPv6's "link" terminology. "Link" 171 replaces OSPF's "subnet" and "network" in most places in this 172 document, although OSPF's Network-LSA remains unchanged (and 173 possibly unfortunately, a new Link-LSA has also been created). 175 The names of some of the OSPF LSAs have also changed. See 176 Section 2.8 for details. 178 2. Differences from OSPF for IPv4 180 Most of the algorithms from OSPF for IPv4 [Ref1] have preserved in 181 OSPF for IPv6. However, some changes have been necessary, either due 182 to changes in protocol semantics between IPv4 and IPv6, or simply to 183 handle the increased address size of IPv6. 185 The following subsections describe the differences between this 186 document and [Ref1]. 188 2.1. Protocol processing per-link, not per-subnet 190 IPv6 uses the term "link" to indicate "a communication facility 191 or medium over which nodes can communicate at the link layer" 192 ([Ref14]). "Interfaces" connect to links. Multiple IP subnets 193 can be assigned to a single link, and two nodes can talk 194 directly over a single link, even if they do not share a common 195 IP subnet (IPv6 prefix). 197 For this reason, OSPF for IPv6 runs per-link instead of the IPv4 198 behavior of per-IP-subnet. The terms "network" and "subnet" used 199 in the IPv4 OSPF specification ([Ref1]) should generally be 200 relaced by link. Likewise, an OSPF interface now connects to a 201 link instead of an IP subnet, etc. 203 This change affects the receiving of OSPF protocol packets, and 204 the contents of Hello Packets and Network-LSAs. 206 2.2. Removal of addressing semantics 208 In OSPF for IPv6, addressing semantics have been removed from 209 the OSPF protocol packets and the main LSA types, leaving a 210 network-protocol-independent core. In particular: 212 o IPv6 Addresses are not present in OSPF packets, except for 213 in LSA payloads carried by the Link State Update Packets. 214 See Section 2.7 for details. 216 o Router-LSAs and Network-LSAs no longer contain network 217 addresses, but simply express topology information. See 218 Section 2.8 for details. 220 o OSPF Router IDs, Area IDs and LSA Link State IDs remain at 221 the IPv4 size of 32-bits. They can no longer be assigned as 222 (IPv6) addresses. 224 o Neighboring routers are now always identified by Router ID, 225 where previously they had been identified by IP address on 226 broadcast and NBMA "networks". 228 2.3. Addition of Flooding scope 230 Flooding scope for LSAs has been generalized and is now 231 explicitly coded in the LSA's LS type field. There are now three 232 separate flooding scopes for LSAs: 234 o Link-local scope. LSA is flooded only on the local link, and 235 no further. Used for the new Link-LSA (see Section A.4.8). 237 o Area scope. LSA is flooded throughout a single OSPF area 238 only. Used for Router-LSAs, Network-LSAs, Inter-Area- 239 Prefix-LSAs, Inter-Area-Router-LSAs and Intra-Area-Prefix- 240 LSAs. 242 o AS scope. LSA is flooded throughout the routing domain. Used 243 for AS-external-LSAs. 245 2.4. Explicit support for multiple instances per link 247 OSPF now supports the ability to run multiple OSPF protocol 248 instances on a single link. For example, this may be required on 249 a NAP segment shared between several providers -- providers may 250 be running separate OSPF routing domains that want to remain 251 separate even though they have one or more physical network 252 segments (i.e., links) in common. In OSPF for IPv4 this was 253 supported in a haphazard fashion using the authentication fields 254 in the OSPF for IPv4 header. 256 Another use for running multiple OSPF instances is if you want, 257 for one reason or another, to have a single link belong to two 258 or more OSPF areas. 260 Support for multiple protocol instances on a link is 261 accomplished via an "Instance ID" contained in the OSPF packet 262 header and OSPF interface structures. Instance ID solely affects 263 the reception of OSPF packets. 265 2.5. Use of link-local addresses 267 IPv6 link-local addresses are for use on a single link, for 268 purposes of neighbor discovery, auto-configuration, etc. IPv6 269 routers do not forward IPv6 datagrams having link-local source 270 addresses [Ref15]. Link-local unicast addresses are assigned 271 from the IPv6 address range FF80/10. 273 OSPF for IPv6 assumes that each router has been assigned link- 274 local unicast addresses on each of the router's attached 275 physical segments. On all OSPF interfaces except virtual links, 276 OSPF packets are sent using the interface's associated link- 277 local unicast address as source. A router learns the link-local 278 addresses of all other routers attached to its links, and uses 279 these addresses as next hop information during packet 280 forwarding. 282 On virtual links, global scope or site-local IP addresses must 283 be used as the source for OSPF protocol packets. 285 Link-local addresses appear in OSPF Link-LSAs (see Section 286 3.4.3.6). However, link-local addresses are not allowed in other 287 OSPF LSA types. In particular, link-local addresses cannot be 288 advertised in inter-area-prefix-LSAs (Section 3.4.3.3), AS- 289 external-LSAs (Section 3.4.3.5) or intra-area-prefix-LSAs 290 (Section 3.4.3.7). 292 2.6. Authentication changes 294 In OSPF for IPv6, authentication has been removed from OSPF 295 itself. The "AuType" and "Authentication" fields have been 296 removed from the OSPF packet header, and all authentication 297 related fields have been removed from the OSPF area and 298 interface structures. 300 When running over IPv6, OSPF relies on the IP Authentication 301 Header (see [Ref19]) and the IP Encapsulating Security Payload 302 (see [Ref20]) to ensure integrity and 303 authentication/confidentiality of routing exchanges. 305 Protection of OSPF packet exchanges against accidental data 306 corruption is provided by the standard IPv6 16-bit one's 307 complement checksum, covering the entire OSPF packet and 308 prepended IPv6 pseudo-header (see Section A.3.1). 310 2.7. Packet format changes 312 OSPF for IPv6 runs directly over IPv6. Aside from this, all 313 addressing semantics have been removed from the OSPF packet 314 headers, making it essentially "network-protocol-independent". 315 All addressing information is now contained in the various LSA 316 types only. 318 In detail, changes in OSPF packet format consist of the 319 following: 321 o The OSPF version number has been increased from 2 to 3. 323 o The Options field in Hello Packets and Database description 324 Packets has been expanded to 24-bits. 326 o The Authentication and AuType fields have been removed from 327 the OSPF packet header (see Section 2.6). 329 o The Hello packet now contains no address information at all, 330 and includes an Interface ID which the originating router 331 has assigned to uniquely identify (among its own interfaces) 332 its interface to the link. This Interface ID becomes the 333 Network-LSA's Link State ID, should the router become 334 Designated Router on the link. 336 o Two options bits, the "R-bit" and the "V6-bit", have been 337 added to the Options field for processing Router-LSAs during 338 the SPF calculation (see Section A.2). If the "R-bit" is 339 clear an OSPF speaker can participate in OSPF topology 340 distribution without being used to forward transit traffic; 341 this can be used in multi-homed hosts that want to 342 participate in the routing protocol. The V6-bit specializes 343 the R-bit; if the V6-bit is clear an OSPF speaker can 344 participate in OSPF topology distribution without being used 345 to forward IPv6 datagrams. If the R-bit is set and the V6- 346 bit is clear, IPv6 datagrams are not forwarded but datagrams 347 belonging to another protocol family may be forwarded. 349 o The OSPF packet header now includes an "Instance ID" which 350 allows multiple OSPF protocol instances to be run on a 351 single link (see Section 2.4). 353 2.8. LSA format changes 355 All addressing semantics have been removed from the LSA header, 356 and from Router-LSAs and Network-LSAs. These two LSAs now 357 describe the routing domain's topology in a network-protocol- 358 independent manner. New LSAs have been added to distribute IPv6 359 address information, and data required for next hop resolution. 360 The names of some of IPv4's LSAs have been changed to be more 361 consistent with each other. 363 In detail, changes in LSA format consist of the following: 365 o The Options field has been removed from the LSA header, 366 expanded to 24 bits, and moved into the body of Router-LSAs, 367 Network-LSAs, Inter-Area-Router-LSAs and Link-LSAs. See 368 Section A.2 for details. 370 o The LSA Type field has been expanded (into the former 371 Options space) to 16 bits, with the upper three bits 372 encoding flooding scope and the handling of unknown LSA 373 types (see Section 2.9). 375 o Addresses in LSAs are now expressed as [prefix, prefix 376 length] instead of [address, mask] (see Section A.4.1). The 377 default route is expressed as a prefix with length 0. 379 o The Router and Network LSAs now have no address information, 380 and are network-protocol-independent. 382 o Router interface information may be spread across multiple 383 Router LSAs. Receivers must concatenate all the Router-LSAs 384 originated by a given router when running the SPF 385 calculation. 387 o A new LSA called the Link-LSA has been introduced. The LSAs 388 have local-link flooding scope; they are never flooded 389 beyond the link that they are associated with. Link-LSAs 390 have three purposes: 1) they provide the router's link-local 391 address to all other routers attached to the link and 2) 392 they inform other routers attached to the link of a list of 393 IPv6 prefixes to associate with the link and 3) they allow 394 the router to assert a collection of Options bits to 395 associate with the Network-LSA that will be originated for 396 the link. See Section A.4.8 for details. 398 In IPv4, the router-LSA carries a router's IPv4 interface 399 addresses, the IPv4 equivalent of link-local addresses. 400 These are only used when calculating next hops during the 401 OSPF routing calculation (see Section 16.1.1 of [Ref1]), so 402 they do not need to be flooded past the local link; hence 403 using link-LSAs to distribute these addresses is more 404 efficient. Note that link-local addresses cannot be learned 405 through the reception of Hellos in all cases: on NBMA links 406 next hop routers do not necessarily exchange hellos, but 407 rather learn of each other's existence by way of the 408 Designated Router. 410 o The Options field in the Network LSA is set to the logical 411 OR of the Options that each router on the link advertises in 412 its Link-LSA. 414 o Type-3 summary-LSAs have been renamed "Inter-Area-Prefix- 415 LSAs". Type-4 summary LSAs have been renamed "Inter-Area- 416 Router-LSAs". 418 o The Link State ID in Inter-Area-Prefix-LSAs, Inter-Area- 419 Router-LSAs and AS-external-LSAs has lost its addressing 420 semantics, and now serves solely to identify individual 421 pieces of the Link State Database. All addresses or Router 422 IDs that formerly were expressed by the Link State ID are 423 now carried in the LSA bodies. 425 o Network-LSAs and Link-LSAs are the only LSAs whose Link 426 State ID carries additional meaning. For these LSAs, the 427 Link State ID is always the Interface ID of the originating 428 router on the link being described. For this reason, 429 Network-LSAs and Link-LSAs are now the only LSAs that cannot 430 be broken into arbitrarily small pieces. 432 o A new LSA called the Intra-Area-Prefix-LSA has been 433 introduced. This LSA carries all IPv6 prefix information 434 that in IPv4 is included in Router-LSAs and Network-LSAs. 436 See Section A.4.9 for details. 438 o Inclusion of a forwarding address in AS-external-LSAs is now 439 optional, as is the inclusion of an external route tag (see 440 [Ref5]). In addition, AS-external-LSAs can now reference 441 another LSA, for inclusion of additional route attributes 442 that are outside the scope of the OSPF protocol itself. For 443 example, this can be used to attach BGP path attributes to 444 external routes as proposed in [Ref10]. 446 2.9. Handling unknown LSA types 448 Handling of unknown LSA types has been made more flexible so 449 that, based on LS type, unknown LSA types are either treated as 450 having link-local flooding scope, or are stored and flooded as 451 if they were understood (desirable for things like the proposed 452 External-Attributes-LSA in [Ref10]). This behavior is explicitly 453 coded in the LSA Handling bit of the link state header's LS type 454 field (see Section A.4.2.1). 456 The IPv4 OSPF behavior of simply discarding unknown types is 457 unsupported due to the desire to mix router capabilities on a 458 single link. Discarding unknown types causes problems when the 459 Designated Router supports fewer options than the other routers 460 on the link. 462 2.10. Stub area support 464 In OSPF for IPv4, stub areas were designed to minimize link- 465 state database and routing table sizes for the areas' internal 466 routers. This allows routers with minimal resources to 467 participate in even very large OSPF routing domains. 469 In OSPF for IPv6, the concept of stub areas is retained. In 470 IPv6, of the mandatory LSA types, stub areas carry only router- 471 LSAs, network-LSAs, Inter-Area-Prefix-LSAs, Link-LSAs, and 472 Intra-Area-Prefix-LSAs. This is the IPv6 equivalent of the LSA 473 types carried in IPv4 stub areas: router-LSAs, network-LSAs and 474 type 3 summary-LSAs. 476 However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS 477 types to be labeled "Store and flood the LSA, as if type 478 understood" (see the U-bit in Section A.4.2.1). Uncontrolled 479 introduction of such LSAs could cause a stub area's link-state 480 database to grow larger than its component routers' capacities. 481 To guard against this, the following rule regarding stub areas 482 has been established: an LSA whose LS type is unrecognized is 483 not flooded into/throughout stub areas if either a) the unknown 484 LSA has AS flooding scope or b) the unknown LSA has U-bit set to 485 1 (flood even when LS type unrecognized). See Section 3.5 for 486 details. 488 2.11. Identifying neighbors by Router ID 490 In OSPF for IPv6, neighboring routers on a given link are always 491 identified by their OSPF Router ID. This contrasts with the IPv4 492 behavior where neighbors on point-to-point networks and virtual 493 links are identified by their Router IDs, and neighbors on 494 broadcast, NBMA and Point-to-MultiPoint links are identified by 495 their IPv4 interface addresses. 497 This change affects the reception of OSPF packets (see Section 498 8.2 of [Ref1]), the lookup of neighbors (Section 10 of [Ref1]) 499 and the reception of Hello Packets (Section 10.5 of [Ref1]). 501 The Router ID of 0.0.0.0 is reserved, and should not be used. 503 3. Implementation details 505 When going from IPv4 to IPv6, the basic OSPF mechanisms remain 506 unchanged from those documented in [Ref1]. These mechanisms are 507 briefly outlined in Section 4 of [Ref1]. Both IPv6 and IPv4 have a 508 link-state database composed of LSAs and synchronized between 509 adjacent routers. Initial synchronization is performed through the 510 Database Exchange process, through the exchange of Database 511 Description, Link State Request and Link State Update packets. 512 Thereafter database synchronization is maintained via flooding, 513 utilizing Link State Update and Link State Acknowledgment packets. 514 Both IPv6 and IPv4 use OSPF Hello Packets to disover and maintain 515 neighbor relationships, and to elect Designated Routers and Backup 516 Designated Routers on broadcast and NBMA links. The decision as to 517 which neighbor relationships become adjacencies, along with the 518 basic ideas behind inter-area routing, importing external 519 information in AS-external-LSAs and the various routing calculations 520 are also the same. 522 In particular, the following IPv4 OSPF functionality described in 523 [Ref1] remains completely unchanged for IPv6: 525 o Both IPv4 and IPv6 use OSPF packet types described in Section 526 4.3 of [Ref1], namely: Hello, Database Description, Link State 527 Request, Link State Update and Link State Acknowledgment 528 packets. While in some cases (e.g., Hello packets) their format 529 has changed somewhat, the functions of the various packet types 530 remains the same. 532 o The system requirements for an OSPF implementation remain 533 unchanged, although OSPF for IPv6 requires an IPv6 protocol 534 stack (from the network layer on down) since it runs directly 535 over the IPv6 network layer. 537 o The discovery and maintenance of neighbor relationships, and the 538 selection and establishment of adjacencies remain the same. This 539 includes election of the Designated Router and Backup Designated 540 Router on broadcast and NBMA links. These mechanisms are 541 described in Sections 7, 7.1, 7.2, 7.3, 7.4 and 7.5 of [Ref1]. 543 o The link types (or equivalently, interface types) supported by 544 OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, 545 Point-to-MultiPoint and virtual links. 547 o The interface state machine, including the list of OSPF 548 interface states and events, and the Designated Router and 549 Backup Designated Router election algorithm, remain unchanged. 550 These are described in Sections 9.1, 9.2, 9.3 and 9.4 of [Ref1]. 552 o The neighbor state machine, including the list of OSPF neighbor 553 states and events, remain unchanged. These are described in 554 Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1]. 556 o Aging of the link-state database, as well as flushing LSAs from 557 the routing domain through the premature aging process, remains 558 unchanged from the description in Sections 14 and 14.1 of 559 [Ref1]. 561 However, some OSPF protocol mechanisms have changed, as outlined in 562 Section 2 above. These changes are explained in detail in the 563 following subsections, making references to the appropriate sections 564 of [Ref1]. 566 The following subsections provide a recipe for turning an IPv4 OSPF 567 implementation into an IPv6 OSPF implementation. 569 3.1. Protocol data structures 571 The major OSPF data structures are the same for both IPv4 and 572 IPv6: areas, interfaces, neighbors, the link-state database and 573 the routing table. The top-level data structures for IPv6 remain 574 those listed in Section 5 of [Ref1], with the following 575 modifications: 577 o All LSAs with known LS type and AS flooding scope appear in 578 the top-level data structure, instead of belonging to a 579 specific area or link. AS-external-LSAs are the only LSAs 580 defined by this specification which have AS flooding scope. 581 LSAs with unknown LS type, U-bit set to 1 (flood even when 582 unrecognized) and AS flooding scope also appear in the top- 583 level data structure. 585 3.1.1. The Area Data structure 587 The IPv6 area data structure contains all elements defined 588 for IPv4 areas in Section 6 of [Ref1]. In addition, all LSAs 589 of known type which have area flooding scope are contained 590 in the IPv6 area data structure. This always includes the 591 following LSA types: router-LSAs, network-LSAs, inter-area- 592 prefix-LSAs, inter-area-router-LSAs and intra-area-prefix- 593 LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even 594 when unrecognized) and area scope also appear in the area 595 data structure. IPv6 routers implementing MOSPF add group- 596 membership-LSAs to the area data structure. Type-7-LSAs 597 belong to an NSSA area's data structure. 599 3.1.2. The Interface Data structure 601 In OSPF for IPv6, an interface connects a router to a link. 602 The IPv6 interface structure modifies the IPv4 interface 603 structure (as defined in Section 9 of [Ref1]) as follows: 605 Interface ID 606 Every interface is assigned an Interface ID, which 607 uniquely identifies the interface with the router. For 608 example, some implementations may be able to use the 609 MIB-II IfIndex as Interface ID. The Interface ID appears 610 in Hello packets sent out the interface, the link- 611 local-LSA originated by router for the attached link, 612 and the router-LSA originated by the router-LSA for the 613 associated area. It will also serve as the Link State ID 614 for the network-LSA that the router will originate for 615 the link if the router is elected Designated Router. 617 Instance ID 618 Every interface is assigned an Instance ID. This should 619 default to 0, and is only necessary to assign 620 differently on those links that will contain multiple 621 separate communities of OSPF Routers. For example, 622 suppose that there are two communities of routers on a 623 given ethernet segment that you wish to keep separate. 624 The first community is given an Instance ID of 0, by 625 assigning 0 as the Instance ID of all its routers' 626 interfaces to the ethernet. An Instance ID of 1 is 627 assigned to the other routers' interfaces to the 628 ethernet. The OSPF transmit and receive processing (see 629 Section 3.2) will then keep the two communities 630 separate. 632 List of LSAs with link-local scope 633 All LSAs with link-local scope and which were 634 originated/flooded on the link belong to the interface 635 structure which connects to the link. This includes the 636 collection of the link's link-LSAs. 638 List of LSAs with unknown LS type 639 All LSAs with unknown LS type and U-bit set to 0 (if 640 unrecognized, treat the LSA as if it had link-local 641 flooding scope) are kept in the data structure for the 642 interface that received the LSA. 644 IP interface address 645 For IPv6, the IPv6 address appearing in the source of 646 OSPF packets sent out the interface is almost always a 647 link-local address. The one exception is for virtual 648 links, which must use one of the router's own site-local 649 or global IPv6 addresses as IP interface address. 651 List of link prefixes 652 A list of IPv6 prefixes can be configured for the 653 attached link. These will be advertised by the router in 654 link-LSAs, so that they can be advertised by the link's 655 Designated Router in intra-area-prefix-LSAs. 657 In OSPF for IPv6, each router interface has a single metric, 658 representing the cost of sending packets out the interface. 659 In addition, OSPF for IPv6 relies on the IP Authentication 660 Header (see [Ref19]) and the IP Encapsulating Security 661 Payload (see [Ref20]) to ensure integrity and 662 authentication/confidentiality of routing exchanges. For 663 that reason, AuType and Authentication key are not 664 associated with IPv6 OSPF interfaces. 666 Interface states, events, and the interface state machine 667 remain unchanged from IPv4, and are documented in Sections 668 9.1, 9.2 and 9.3 of [Ref1] respectively. The Designated 669 Router and Backup Designated Router election algorithm also 670 remains unchanged from the IPv4 election in Section 9.4 of 671 [Ref1]. 673 3.1.3. The Neighbor Data Structure 675 The neighbor structure performs the same function in both 676 IPv6 and IPv4. Namely, it collects all information required 677 to form an adjacency between two routers, if an adjacency 678 becomes necessary. Each neighbor structure is bound to a 679 single OSPF interface. The differences between the IPv6 680 neighbor structure and the neighbor structure defined for 681 IPv4 in Section 10 of [Ref1] are: 683 Neighbor's Interface ID 684 The Interface ID that the neighbor advertises in its 685 Hello Packets must be recorded in the neighbor 686 structure. The router will include the neighbor's 687 Interface ID in the router's router-LSA when either a) 688 advertising a point-to-point link to the neighbor or b) 689 advertising a link to a network where the neighbor has 690 become Designated Router. 692 Neighbor IP address 693 Except on virtual links, the neighbor's IP address will 694 be an IPv6 link-local address. 696 Neighbor's Designated Router 697 The neighbor's choice of Designated Router is now 698 encoded as a Router ID, instead of as an IP address. 700 Neighbor's Backup Designated Router 701 The neighbor's choice of Designated Router is now 702 encoded as a Router ID, instead of as an IP address. 704 Neighbor states, events, and the neighbor state machine 705 remain unchanged from IPv4, and are documented in Sections 706 10.1, 10.2 and 10.3 of [Ref1] respectively. The decision as 707 to which adjacencies to form also remains unchanged from the 708 IPv4 logic documented in Section 10.4 of [Ref1]. 710 3.2. Protocol Packet Processing 712 OSPF for IPv6 runs directly over IPv6's network layer. As such, 713 it is encapsulated in one or more IPv6 headers, with the Next 714 Header field of the immediately encapsulating IPv6 header set to 715 the value 89. 717 As for IPv4, in IPv6 OSPF routing protocol packets are sent 718 along adjacencies only (with the exception of Hello packets, 719 which are used to discover the adjacencies). OSPF packet types 720 and functions are the same in both IPv4 and IPv4, encoded by the 721 Type field of the standard OSPF packet header. 723 3.2.1. Sending protocol packets 725 When an IPv6 router sends an OSPF routing protocol packet, 726 it fills in the fields of the standard OSPF for IPv6 packet 727 header (see Section A.3.1) as follows: 729 Version # 730 Set to 3, the version number of the protocol as 731 documented in this specification. 733 Type 734 The type of OSPF packet, such as Link state Update or 735 Hello Packet. 737 Packet length 738 The length of the entire OSPF packet in bytes, including 739 the standard OSPF packet header. 741 Router ID 742 The identity of the router itself (who is originating 743 the packet). 745 Area ID 746 The OSPF area that the packet is being sent into. 748 Instance ID 749 The OSPF Instance ID associated with the interface that 750 the packet is being sent out of. 752 Checksum 753 The standard IPv6 16-bit one's complement checksum, 754 covering the entire OSPF packet and prepended IPv6 755 pseudo-header (see Section A.3.1). 757 Selection of OSPF routing protocol packets' IPv6 source and 758 destination addresses is performed identically to the IPv4 759 logic in Section 8.1 of [Ref1]. The IPv6 destination address 760 is chosen from among the addresses AllSPFRouters, 761 AllDRouters and the Neighbor IP address associated with the 762 other end of the adjacency (which in IPv6, for all links 763 except virtual links, is an IPv6 link-local address). 765 The sending of Link State Request Packets and Link State 766 Acknowledgment Packets remains unchanged from the IPv4 767 procedures documented in Sections 10.9 and 13.5 of [Ref1] 768 respectively. Sending Hello Packets is documented in Section 769 3.2.1.1, and the sending of Database Description Packets in 770 Section 3.2.1.2. The sending of Link State Update Packets is 771 documented in Section 3.5.2. 773 3.2.1.1. Sending Hello packets 775 IPv6 changes the way OSPF Hello packets are sent in the 776 following ways (compare to Section 9.5 of [Ref1]): 778 o Before the Hello Packet is sent out an interface, 779 the interface's Interface ID must be copied into the 780 Hello Packet. 782 o The Hello Packet no longer contains an IP network 783 mask, as OSPF for IPv6 runs per-link instead of 784 per-subnet. 786 o The choice of Designated Router and Backup 787 Designated Router are now indicated within Hellos by 788 their Router IDs, instead of by their IP interface 789 addresses. Advertising the Designated Router (or 790 Backup Designated Router) as 0.0.0.0 indicates that 791 the Designated Router (or Backup Designated Router) 792 has not yet been chosen. 794 o The Options field within Hello packets has moved 795 around, getting larger in the process. More options 796 bits are now possible. Those that must be set 797 correctly in Hello packets are: The E-bit is set if 798 and only if the interface attaches to a non-stub 799 area, the N-bit is set if and only if the interface 800 attaches to an NSSA area (see [Ref9]), and the DC- 801 bit is set if and only if the router wishes to 802 suppress the sending of future Hellos over the 803 interface (see [Ref11]). Unrecognized bits in the 804 Hello Packet's Options field should be cleared. 806 Sending Hello packets on NBMA networks proceeds for IPv6 807 in exactly the same way as for IPv4, as documented in 808 Section 9.5.1 of [Ref1]. 810 3.2.1.2. Sending Database Description Packets 812 The sending of Database Description packets differs from 813 Section 10.8 of [Ref1] in the following ways: 815 o The Options field within Database Description 816 packets has moved around, getting larger in the 817 process. More options bits are now possible. Those 818 that must be set correctly in Database Description 819 packets are: The MC-bit is set if and only if the 820 router is forwarding multicast datagrams according 821 to the MOSPF specification in [Ref7], and the DC-bit 822 is set if and only if the router wishes to suppress 823 the sending of Hellos over the interface (see 824 [Ref11]). Unrecognized bits in the Database 825 Description Packet's Options field should be 826 cleared. 828 3.2.2. Receiving protocol packets 830 Whenever an OSPF protocol packet is received by the router 831 it is marked with the interface it was received on. For 832 routers that have virtual links configured, it may not be 833 immediately obvious which interface to associate the packet 834 with. For example, consider the Router RT11 depicted in 835 Figure 6 of [Ref1]. If RT11 receives an OSPF protocol 836 packet on its interface to Network N8, it may want to 837 associate the packet with the interface to Area 2, or with 838 the virtual link to Router RT10 (which is part of the 839 backbone). In the following, we assume that the packet is 840 initially associated with the non-virtual link. 842 In order for the packet to be passed to OSPF for processing, 843 the following tests must be performed on the encapsulating 844 IPv6 headers: 846 o The packet's IP destination address must be one of the 847 IPv6 unicast addresses associated with the receiving 848 interface (this includes link-local addresses), or one 849 of the IP multicast addresses AllSPFRouters or 850 AllDRouters. 852 o The Next Header field of the immediately encapsulating 853 IPv6 header must specify the OSPF protocol (89). 855 o Any encapsulating IP Authentication Headers (see 856 [Ref19]) and the IP Encapsulating Security Payloads (see 857 [Ref20]) must be processed and/or verified to ensure 858 integrity and authentication/confidentiality of OSPF 859 routing exchanges. 861 o Locally originated packets should not be passed on to 862 OSPF. That is, the source IPv6 address should be 863 examined to make sure this is not a multicast packet 864 that the router itself generated. 866 After processing the encapsulating IPv6 headers, the OSPF 867 packet header is processed. The fields specified in the 868 header must match those configured for the receiving 869 interface. If they do not, the packet should be discarded: 871 o The version number field must specify protocol version 872 3. 874 o The standard IPv6 16-bit one's complement checksum, 875 covering the entire OSPF packet and prepended IPv6 876 pseudo-header, must be verified (see Section A.3.1). 878 o The Area ID found in the OSPF header must be verified. 879 If both of the following cases fail, the packet should 880 be discarded. The Area ID specified in the header must 881 either: 883 (1) Match the Area ID of the receiving interface. In 884 this case, unlike for IPv4, the IPv6 source address 885 is not restricted to lie on the same IP subnet as 886 the receiving interface. IPv6 OSPF runs per-link, 887 instead of per-IP-subnet. 889 (2) Indicate the backbone. In this case, the packet has 890 been sent over a virtual link. The receiving router 891 must be an area border router, and the Router ID 892 specified in the packet (the source router) must be 893 the other end of a configured virtual link. The 894 receiving interface must also attach to the virtual 895 link's configured Transit area. If all of these 896 checks succeed, the packet is accepted and is from 897 now on associated with the virtual link (and the 898 backbone area). 900 o The Instance ID specified in the OSPF header must match 901 the receiving interface's Instance ID. 903 o Packets whose IP destination is AllDRouters should only 904 be accepted if the state of the receiving interface is 905 DR or Backup (see Section 9.1). 907 After header processing, the packet is further processed 908 according to it OSPF packet type. OSPF packet types and 909 functions are the same for both IPv4 and IPv6. 911 If the packet type is Hello, it should then be further 912 processed by the Hello Protocol. All other packet types are 913 sent/received only on adjacencies. This means that the 914 packet must have been sent by one of the router's active 915 neighbors. The neighbor is identified by the Router ID 916 appearing the the received packet's OSPF header. Packets not 917 matching any active neighbor are discarded. 919 The receive processing of Database Description Packets, Link 920 State Request Packets and Link State Acknowledgment Packets 921 remains unchanged from the IPv4 procedures documented in 922 Sections 10.6, 10.7 and 13.7 of [Ref1] respectively. The 923 receiving of Hello Packets is documented in Section 3.2.2.1, 924 and the receiving of Link State Update Packets is documented 925 in Section 3.5.1. 927 3.2.2.1. Receiving Hello Packets 929 The receive processing of Hello Packets differs from 930 Section 10.5 of [Ref1] in the following ways: 932 o On all link types (e.g., broadcast, NBMA, point-to- 933 point, etc), neighbors are identified solely by 934 their OSPF Router ID. For all link types except 935 virtual links, the Neighbor IP address is set to the 936 IPv6 source address in the IPv6 header of the 937 received OSPF Hello packet. 939 o There is no longer a Network Mask field in the Hello 940 Packet. 942 o The neighbor's choice of Designated Router and 943 Backup Designated Router is now encoded as an OSPF 944 Router ID instead of an IP interface address. 946 3.3. The Routing table Structure 948 The routing table used by OSPF for IPv4 is defined in Section 11 949 of [Ref1]. For IPv6 there are analogous routing table entries: 950 there are routing table entries for IPv6 address prefixes, and 951 also for AS boundary routers. The latter routing table entries 952 are only used to hold intermediate results during the routing 953 table build process (see Section 3.8). 955 Also, to hold the intermediate results during the shortest-path 956 calculation for each area, there is a separate routing table for 957 each area holding the following entries: 959 o An entry for each router in the area. Routers are identified 960 by their OSPF router ID. These routing table entries hold 961 the set of shortest paths through a given area to a given 962 router, which in turn allows calculation of paths to the 963 IPv6 prefixes advertised by that router in Intra-area- 964 prefix-LSAs. If the router is also an area-border router, 965 these entries are also used to calculate paths for inter- 966 area address prefixes. If in addition the router is the 967 other endpoint of a virtual link, the routing table entry 968 describes the cost and viability of the virtual link. 970 o An entry for each transit link in the area. Transit links 971 have associated network-LSAs. Both the transit link and the 972 network-LSA are identified by a combination of the 973 Designated Router's Interface ID on the link and the 974 Designated Router's OSPF Router ID. These routing table 975 entries allow later calculation of paths to IP prefixes 976 advertised for the transit link in intra-area-prefix-LSAs. 978 The fields in the IPv4 OSPF routing table (see Section 11 of 979 [Ref1]) remain valid for IPv6: Optional capabilities (routers 980 only), path type, cost, type 2 cost, link state origin, and for 981 each of the equal cost paths to the destination, the next hop 982 and advertising router. 984 For IPv6, the link-state origin field in the routing table entry 985 is the router-LSA or network-LSA that has directly or indirectly 986 produced the routing table entry. For example, if the routing 987 table entry describes a route to an IPv6 prefix, the link state 988 origin is the router-LSA or network-LSA that is listed in the 989 body of the intra-area-prefix-LSA that has produced the route 990 (see Section A.4.9). 992 3.3.1. Routing table lookup 994 Routing table lookup (i.e., determining the best matching 995 routing table entry during IP forwarding) is the same for 996 IPv6 as for IPv4. 998 3.4. Link State Advertisements 1000 For IPv6, the OSPF LSA header has changed slightly, with the LS 1001 type field expanding and the Options field being moved into the 1002 body of appropriate LSAs. Also, the formats of some LSAs have 1003 changed somewhat (namely router-LSAs, network-LSAs and AS- 1004 external-LSAs), while the names of other LSAs have been changed 1005 (type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and 1006 inter-area-router-LSAs respectively) and additional LSAs have 1007 been added (Link-LSAs and Intra-Area-Prefix-LSAs). Type of 1008 Service (TOS) has been removed from the OSPFv2 specification 1009 [Ref1], and is not encoded within OSPF for IPv6's LSAs. 1011 These changes will be described in detail in the following 1012 subsections. 1014 3.4.1. The LSA Header 1016 In both IPv4 and IPv6, all OSPF LSAs begin with a standard 1017 20 byte LSA header. However, the contents of this 20 byte 1018 header have changed in IPv6. The LS age, Advertising Router, 1019 LS Sequence Number, LS checksum and length fields within the 1020 LSA header remain unchanged, as documented in Sections 1021 12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1 of [Ref1] 1022 respectively. However, the following fields have changed 1023 for IPv6: 1025 Options 1026 The Options field has been removed from the standard 20 1027 byte LSA header, and into the body of router-LSAs, 1028 network-LSAs, inter-area-router-LSAs and link-LSAs. The 1029 size of the Options field has increased from 8 to 24 1030 bits, and some of the bit definitions have changed (see 1031 Section A.2). In addition a separate PrefixOptions 1032 field, 8 bits in length, is attached to each prefix 1033 advertised within the body of an LSA. 1035 LS type 1036 The size of the LS type field has increased from 8 to 16 1037 bits, with the top two bits encoding flooding scope and 1038 the next bit encoding the handling of unknown LS types. 1039 See Section A.4.2.1 for the current coding of the LS 1040 type field. 1042 Link State ID 1043 Link State ID remains at 32 bits in length, but except 1044 for network-LSAs and link-LSAs, Link State ID has shed 1045 any addressing semantics. For example, an IPv6 router 1046 originating multiple AS-external-LSAs could start by 1047 assigning the first a Link State ID of 0.0.0.1, the 1048 second a Link State ID of 0.0.0.2, and so on. Instead of 1049 the IPv4 behavior of encoding the network number within 1050 the AS-external-LSA's Link State ID, the IPv6 Link State 1051 ID simply serves as a way to differentiate multiple LSAs 1052 originated by the same router. 1054 For network-LSAs, the Link State ID is set to the 1055 Designated Router's Interface ID on the link. When a 1056 router originates a Link-LSA for a given link, its Link 1057 State ID is set equal to the router's Interface ID on 1058 the link. 1060 3.4.2. The link-state database 1062 In IPv6, as in IPv4, individual LSAs are identified by a 1063 combination of their LS type, Link State ID and Advertising 1064 Router fields. Given two instances of an LSA, the most 1065 recent instance is determined by examining the LSAs' LS 1066 Sequence Number, using LS checksum and LS age as tiebreakers 1067 (see Section 13.1 of [Ref1]). 1069 In IPv6, the link-state database is split across three 1070 separate data structures. LSAs with AS flooding scope are 1071 contained within the top-level OSPF data structure (see 1072 Section 3.1) as long as either their LS type is known or 1073 their U-bit is 1 (flood even when unrecognized); this 1074 includes the AS-external-LSAs. LSAs with area flooding scope 1075 are contained within the appropriate area structure (see 1076 Section 3.1.1) as long as either their LS type is known or 1077 their U-bit is 1 (flood even when unrecognized); this 1078 includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, 1079 inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs 1080 with unknown LS type and U-bit set to 0 and/or link-local 1081 flooding scope are contained within the appropriate 1082 interface structure (see Section 3.1.2); this includes 1083 link-LSAs. 1085 To lookup or install an LSA in the database, you first 1086 examine the LS type and the LSA's context (i.e., to which 1087 area or link does the LSA belong). This information allows 1088 you to find the correct list of LSAs, all of the same LS 1089 type, where you then search based on the LSA's Link State ID 1090 and Advertising Router. 1092 3.4.3. Originating LSAs 1094 The process of reoriginating an LSA in IPv6 is the same as 1095 in IPv4: the LSA's LS sequence number is incremented, its 1096 LS age is set to 0, its LS checksum is calculated, and the 1097 LSA is added to the link state database and flooded out the 1098 appropriate interfaces. 1100 To the list of events causing LSAs to be reoriginated, which 1101 for IPv4 is given in Section 12.4 of [Ref1], the following 1102 events are added for IPv6: 1104 o The Interface ID of a neighbor changes. This may cause a 1105 new instance of a router-LSA to be originated for the 1106 associated area. 1108 o A new prefix is added to an attached link, or a prefix 1109 is deleted (both through configuration). This causes the 1110 router to reoriginate its link-LSA for the link, or, if 1111 it is the only router attached to the link, causes the 1112 router to reoriginate an intra-area-prefix-LSA. 1114 o A new link-LSA is received, causing the link's 1115 collection of prefixes to change. If the router is 1116 Designated Router for the link, it originates a new 1117 intra-area-prefix-LSA. 1119 Detailed construction of the seven required IPv6 LSA types 1120 is supplied by the following subsections. In order to 1121 display example LSAs, the network map in Figure 15 of [Ref1] 1122 has been reworked to show IPv6 addressing, resulting in 1123 Figure 1. The OSPF cost of each interface is has been 1124 displayed in Figure 1. The assignment of IPv6 prefixes to 1125 network links is shown in Table 1. A single area address 1126 range has been configured for Area 1, so that outside of 1127 Area 1 all of its prefixes are covered by a single route to 1128 5f00:0000:c001::/48. The OSPF interface IDs and the link- 1129 local addresses for the router interfaces in Figure 1 are 1130 given in Table 2. 1132 Network IPv6 prefix 1133 __________________________________ 1134 N1 5f00:0000:c001:0200::/56 1135 N2 5f00:0000:c001:0300::/56 1136 N3 5f00:0000:c001:0100::/56 1137 N4 5f00:0000:c001:0400::/56 1139 Table 1: IPv6 link prefixes for sample network 1140 .......................................... 1141 . Area 1. 1142 . + . 1143 . | . 1144 . | 3+---+1 . 1145 . N1 |--|RT1|-----+ . 1146 . | +---+ \ . 1147 . | \ ______ . 1148 . + \/ \ 1+---+ 1149 . * N3 *------|RT4|------ 1150 . + /\_______/ +---+ 1151 . | / | . 1152 . | 3+---+1 / | . 1153 . N2 |--|RT2|-----+ 1| . 1154 . | +---+ +---+ . 1155 . | |RT3|---------------- 1156 . + +---+ . 1157 . |2 . 1158 . | . 1159 . +------------+ . 1160 . N4 . 1161 .......................................... 1163 Figure 1: Area 1 with IP addresses shown 1165 Router interface Interface ID link-local address 1166 ______________________________________________________ 1167 RT1 to N1 1 fe80:0001::RT1 1168 to N3 2 fe80:0002::RT1 1169 RT2 to N2 1 fe80:0001::RT2 1170 to N3 2 fe80:0002::RT2 1171 RT3 to N3 1 fe80:0001::RT3 1172 to N4 2 fe80:0002::RT3 1173 RT4 to N3 1 fe80:0001::RT4 1175 Table 2: OSPF Interface IDs and link-local addresses 1177 3.4.3.1. Router-LSAs 1179 The LS type of a router-LSA is set to the value 0x2001. 1180 Router-LSAs have area flooding scope. A router may 1181 originate one or more router-LSAs for a given area. 1182 Taken together, the collection of router-LSAs originated 1183 by the router for an area describes the collected states 1184 of all the router's interfaces to the area. When 1185 multiple router-LSAs are used, they are distinguished by 1186 their Link State ID fields. 1188 The Options field in the router-LSA should be coded as 1189 follows. The V6-bit should be set. The E-bit should be 1190 clear if and only if the attached area is an OSPF stub 1191 area. The MC-bit should be set if and only if the router 1192 is running MOSPF (see [Ref8]). The N-bit should be set 1193 if and only if the attached area is an OSPF NSSA area. 1194 The R-bit should be set. The DC-bit should be set if and 1195 only if the router can correctly process the DoNotAge 1196 bit when it appears in the LS age field of LSAs (see 1197 [Ref11]). All unrecognized bits in the Options field 1198 should be cleared 1200 To the left of the Options field, the router capability 1201 bits V, E and B should be coded according to Section 1202 12.4.1 of [Ref1]. Bit W should be coded according to 1203 [Ref8]. 1205 Each of the router's interfaces to the area are then 1206 described by appending "link descriptions" to the 1207 router-LSA. Each link description is 16 bytes long, 1208 consisting of 5 fields: (link) Type, Metric, Interface 1209 ID, Neighbor Interface ID and Neighbor Router ID (see 1210 Section A.4.3). Interfaces in state "Down" or "Loopback" 1211 are not described (although looped back interfaces can 1212 contribute prefixes to Intra-Area-Prefix-LSAs). Nor are 1213 interfaces without any full adjacencies described. All 1214 other interfaces to the area add zero, one or more link 1215 descriptions, the number and content of which depend on 1216 the interface type. Within each link description, the 1217 Metric field is always set the interface's output cost 1218 and the Interface ID field is set to the interface's 1219 OSPF Interface ID. 1221 Point-to-point interfaces 1222 If the neighboring router is fully adjacent, add a 1223 Type 1 link description (point-to-point). The 1224 Neighbor Interface ID field is set to the Interface 1225 ID advertised by the neighbor in its Hello packets, 1226 and the Neighbor Router ID field is set to the 1227 neighbor's Router ID. 1229 Broadcast and NBMA interfaces 1230 If the router is fully adjacent to the link's 1231 Designated Router, or if the router itself is 1232 Designated Router and is fully adjacent to at least 1233 one other router, add a single Type 2 link 1234 description (transit network). The Neighbor 1235 Interface ID field is set to the Interface ID 1236 advertised by the Designated Router in its Hello 1237 packets, and the Neighbor Router ID field is set to 1238 the Designated Router's Router ID. 1240 Virtual links 1241 If the neighboring router is fully adjacent, add a 1242 Type 4 link description (virtual). The Neighbor 1243 Interface ID field is set to the Interface ID 1244 advertised by the neighbor in its Hello packets, and 1245 the Neighbor Router ID field is set to the 1246 neighbor's Router ID. Note that the output cost of a 1247 virtual link is calculated during the routing table 1248 calculation (see Section 3.7). 1250 Point-to-MultiPoint interfaces 1251 For each fully adjacent neighbor associated with the 1252 interface, add a separate Type 1 link description 1253 (point-to-point) with Neighbor Interface ID field 1254 set to the Interface ID advertised by the neighbor 1255 in its Hello packets, and Neighbor Router ID field 1256 set to the neighbor's Router ID. 1258 As an example, consider the router-LSA that router RT3 1259 would originate for Area 1 in Figure 1. Only a single 1260 interface must be described, namely that which connects 1261 to the transit network N3. It assumes that RT4 has been 1262 elected Designated Router of Network N3. 1264 ; RT3's router-LSA for Area 1 1266 LS age = 0 ;newly (re)originated 1267 LS type = 0x2001 ;router-LSA 1268 Link State ID = 0 ;first fragment 1269 Advertising Router = 192.1.1.3 ;RT3's Router ID 1270 bit E = 0 ;not an AS boundary router 1271 bit B = 1 ;area border router 1272 Options = (V6-bit|E-bit|R-bit) 1273 Type = 2 ;connects to N3 1274 Metric = 1 ;cost to N3 1275 Interface ID = 1 ;RT3's Interface ID on N3 1276 Neighbor Interface ID = 1 ;RT4's Interface ID on N3 1277 Neighbor Router ID = 192.1.1.4 ; RT4's Router ID 1278 If for example another router was added to Network N4, 1279 RT3 would have to advertise a second link description 1280 for its connection to (the now transit) network N4. This 1281 could be accomplished by reoriginating the above 1282 router-LSA, this time with two link descriptions. Or, a 1283 separate router-LSA could be originated with a separate 1284 Link State ID (e.g., using a Link State ID of 1) to 1285 describe the connection to N4. 1287 Host routes no longer appear in the router-LSA, but are 1288 instead included in intra-area-prefix-LSAs. 1290 3.4.3.2. Network-LSAs 1292 The LS type of a network-LSA is set to the value 0x2002. 1293 Network-LSAs have area flooding scope. A network-LSA is 1294 originated for every transit broadcast or NBMA link, by 1295 the link's Designated Router. Transit links are those 1296 that have two or more attached routers. The network-LSA 1297 lists all routers attached to the link. 1299 The procedure for originating network-LSAs in IPv6 is 1300 the same as the IPv4 procedure documented in Section 1301 12.4.2 of [Ref1], with the following exceptions: 1303 o An IPv6 network-LSA's Link State ID is set to the 1304 Interface ID of the Designated Router on the link. 1306 o IPv6 network-LSAs do not contain a Network Mask. All 1307 addressing information formerly contained in the 1308 IPv4 network-LSA has now been consigned to intra- 1309 Area-Prefix-LSAs. 1311 o The Options field in the network-LSA is set to the 1312 logical OR of the Options fields contained within 1313 the link's associated link-LSAs. In this way, the 1314 network link exhibits a capability when at least one 1315 of the link's routers requests that the capability 1316 be asserted. 1318 As an example, assuming that Router RT4 has been elected 1319 Designated Router of Network N3 in Figure 1, the 1320 following network-LSA is originated: 1322 ; Network-LSA for Network N3 1324 LS age = 0 ;newly (re)originated 1325 LS type = 0x2002 ;network-LSA 1326 Link State ID = 1 ;RT4's Interface ID on N3 1327 Advertising Router = 192.1.1.4 ;RT4's Router ID 1328 Options = (V6-bit|E-bit|R-bit) 1329 Attached Router = 192.1.1.4 ;Router ID 1330 Attached Router = 192.1.1.1 ;Router ID 1331 Attached Router = 192.1.1.2 ;Router ID 1332 Attached Router = 192.1.1.3 ;Router ID 1334 3.4.3.3. Inter-Area-Prefix-LSAs 1336 The LS type of an inter-area-prefix-LSA is set to the 1337 value 0x2003. Inter-area-prefix-LSAs have area flooding 1338 scope. In IPv4, inter-area-prefix-LSAs were called type 1339 3 summary-LSAs. Each inter-area-prefix-LSA describes a 1340 prefix external to the area, yet internal to the 1341 Autonomous System. 1343 The procedure for originating inter-area-prefix-LSAs in 1344 IPv6 is the same as the IPv4 procedure documented in 1345 Sections 12.4.3 and 12.4.3.1 of [Ref1], with the 1346 following exceptions: 1348 o The Link State ID of an inter-area-prefix-LSA has 1349 lost all of its addressing semantics, and instead 1350 simply serves to distinguish multiple inter-area- 1351 prefix-LSAs that are originated by the same router. 1353 o The prefix is described by the PrefixLength, 1354 PrefixOptions and Address Prefix fields embedded 1355 within the LSA body. Network Mask is no longer 1356 specified. 1358 o The NU-bit in the PrefixOptions field should be 1359 clear. The coding of the MC-bit depends upon 1360 whether, and if so how, MOSPF is operating in the 1361 routing domain (see [Ref8]). 1363 o Link-local addresses can never be advertised in 1364 inter-area-prefix-LSAs. 1366 As an example, the following shows the inter-area- 1367 prefix-LSA that Router RT4 originates into the OSPF 1368 backbone area, condensing all of Area 1's prefixes into 1369 the single prefix 5f00:0000:c001::/48. The cost is set 1370 to 4, which is the maximum cost to all of the prefix' 1371 individual components. The prefix is padded out to an 1372 even number of 32-bit words, so that it consumes 64-bits 1373 of space instead of 48 bits. 1375 ; Inter-area-prefix-LSA for Area 1 addresses 1376 ; originated by Router RT4 into the backbone 1378 LS age = 0 ;newly (re)originated 1379 LS type = 0x2003 ;inter-area-prefix-LSA 1380 Advertising Router = 192.1.1.4 ;RT4's ID 1381 Metric = 4 ;maximum to components 1382 PrefixLength = 48 1383 PrefixOptions = 0 1384 Address Prefix = 5f00:0000:c001 ;padded to 64-bits 1386 3.4.3.4. Inter-Area-Router-LSAs 1388 The LS type of an inter-area-router-LSA is set to the 1389 value 0x2004. Inter-area-router-LSAs have area flooding 1390 scope. In IPv4, inter-area-router-LSAs were called type 1391 4 summary-LSAs. Each inter-area-router-LSA describes a 1392 path to a destination OSPF router (an ASBR) that is 1393 external to the area, yet internal to the Autonomous 1394 System. 1396 The procedure for originating inter-area-router-LSAs in 1397 IPv6 is the same as the IPv4 procedure documented in 1398 Section 12.4.3 of [Ref1], with the following exceptions: 1400 o The Link State ID of an inter-area-router-LSA is no 1401 longer the destination router's OSPF Router ID, but 1402 instead simply serves to distinguish multiple 1403 inter-area-router-LSAs that are originated by the 1404 same router. The destination router's Router ID is 1405 now found in the body of the LSA. 1407 o The Options field in an inter-area-router-LSA should 1408 be set equal to the Options field contained in the 1409 destination router's own router-LSA. The Options 1410 field thus describes the capabilities supported by 1411 the destination router. 1413 As an example, consider the OSPF Autonomous System 1414 depicted in Figure 6 of [Ref1]. Router RT4 would 1415 originate into Area 1 the following inter-area-router- 1416 LSA for destination router RT7. 1418 ; inter-area-router-LSA for AS boundary router RT7 1419 ; originated by Router RT4 into Area 1 1421 LS age = 0 ;newly (re)originated 1422 LS type = 0x2004 ;inter-area-router-LSA 1423 Advertising Router = 192.1.1.4 ;RT4's ID 1424 Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities 1425 Metric = 14 ;cost to RT7 1426 Destination Router ID = Router RT7's ID 1428 3.4.3.5. AS-external-LSAs 1430 The LS type of an AS-external-LSA is set to the value 1431 0x4005. AS-external-LSAs have AS flooding scope. Each 1432 AS-external-LSA describes a path to a prefix external to 1433 the Autonomous System. 1435 The procedure for originating AS-external-LSAs in IPv6 1436 is the same as the IPv4 procedure documented in Section 1437 12.4.4 of [Ref1], with the following exceptions: 1439 o The Link State ID of an AS-external-LSA has lost all 1440 of its addressing semantics, and instead simply 1441 serves to distinguish multiple AS-external-LSAs that 1442 are originated by the same router. 1444 o The prefix is described by the PrefixLength, 1445 PrefixOptions and Address Prefix fields embedded 1446 within the LSA body. Network Mask is no longer 1447 specified. 1449 o The NU-bit in the PrefixOptions field should be 1450 clear. The coding of the MC-bit depends upon 1451 whether, and if so how, MOSPF is operating in the 1452 routing domain (see [Ref8]). 1454 o Link-local addresses can never be advertised in AS- 1455 external-LSAs. 1457 o The forwarding address is present in the AS- 1458 external-LSA if and only if the AS-external-LSA's 1459 bit F is set. 1461 o The external route tag is present in the AS- 1462 external-LSA if and only if the AS-external-LSA's 1463 bit T is set. 1465 o The capability for an AS-external-LSA to reference 1466 another LSA has been included, by inclusion of the 1467 Referenced LS Type field and the optional Referenced 1468 Link State ID field (the latter present if and only 1469 if Referenced LS Type is non-zero). This capability 1470 is for future use; for now Referenced LS Type should 1471 be set to 0. 1473 As an example, consider the OSPF Autonomous System 1474 depicted in Figure 6 of [Ref1]. Assume that RT7 has 1475 learned its route to N12 via BGP, and that it wishes to 1476 advertise a Type 2 metric into the AS. Further assume 1477 the the IPv6 prefix for N12 is the value 1478 5f00:0000:0a00::/40. RT7 would then originate the 1479 following AS-external-LSA for the external network N12. 1480 Note that within the AS-external-LSA, N12's prefix 1481 occupies 64 bits of space, to maintain 32-bit alignment. 1483 ; AS-external-LSA for Network N12, 1484 ; originated by Router RT7 1486 LS age = 0 ;newly (re)originated 1487 LS type = 0x4005 ;AS-external-LSA 1488 Link State ID = 123 ;or something else 1489 Advertising Router = Router RT7's ID 1490 bit E = 1 ;Type 2 metric 1491 bit F = 0 ;no forwarding address 1492 bit T = 1 ;external route tag included 1493 Metric = 2 1494 PrefixLength = 40 1495 PrefixOptions = 0 1496 Referenced LS Type = 0 ;no Referenced Link State ID 1497 Address Prefix = 5f00:0000:0a00 ;padded to 64-bits 1498 External Route Tag = as per BGP/OSPF interaction 1500 3.4.3.6. Link-LSAs 1502 The LS type of a Link-LSA is set to the value 0x0008. 1503 Link-LSAs have link-local flooding scope. A router 1504 originates a separate Link-LSA for each attached link 1505 that supports 2 or more (including the originating 1506 router itself) routers. 1508 Link-LSAs have three purposes: 1) they provide the 1509 router's link-local address to all other routers 1510 attached to the link and 2) they inform other routers 1511 attached to the link of a list of IPv6 prefixes to 1512 associate with the link and 3) they allow the router to 1513 assert a collection of Options bits in the Network-LSA 1514 that will be originated for the link. 1516 A Link-LSA for a given Link L is built in the following 1517 fashion: 1519 o The Link State ID is set to the router's Interface 1520 ID on Link L. 1522 o The Router Priority of the router's interface to 1523 Link L is inserted into the Link-LSA. 1525 o The Link-LSA's Options field is set to those bits 1526 that the router wishes set in Link L's Network LSA. 1528 o The router inserts its link-local address on Link L 1529 into the Link-LSA. This information will be used 1530 when the other routers on Link L do their next hop 1531 calculations (see Section 3.8.1.1). 1533 o Each IPv6 address prefix that has been configured 1534 into the router for Link L is added to the Link-LSA, 1535 by specifying values for PrefixLength, 1536 PrefixOptions, and Address Prefix fields. 1538 After building a Link-LSA for a given link, the router 1539 installs the link-LSA into the associate interface data 1540 structure and floods the Link-LSA onto the link. All 1541 other routers on the link will receive the Link-LSA, but 1542 it will go no further. 1544 As an example, consider the Link-LSA that RT3 will build 1545 for N3 in Figure 1. Suppose that the prefix 1546 5f00:0000:c001:0100::/56 has been configured within RT3 1547 for N3. This will give rise to the following Link-LSA, 1548 which RT3 will flood onto N3, but nowhere else. Note 1549 that not all routers on N3 need be configured with the 1550 prefix; those not configured will learn the prefix when 1551 receiving RT3's Link-LSA. 1553 ; RT3's Link-LSA for N3 1555 LS age = 0 ;newly (re)originated 1556 LS type = 0x0008 ;Link-LSA 1557 Link State ID = 1 ;RT3's Interface ID on N3 1558 Advertising Router = 192.1.1.3 ;RT3's Router ID 1559 Rtr Pri = 1 ;RT3's N3 Router Priority 1560 Options = (V6-bit|E-bit|R-bit) 1561 Link-local Interface Address = fe80:0001::RT3 1562 # prefixes = 1 1563 PrefixLength = 56 1564 PrefixOptions = 0 1565 Address Prefix = 5f00:0000:c001:0100 ;pad to 64-bits 1566 3.4.3.7. Intra-Area-Prefix-LSAs 1568 The LS type of an intra-area-prefix-LSA is set to the 1569 value 0x2009. Intra-area-prefix-LSAs have area flooding 1570 scope. An intra-area-prefix-LSA has one of two 1571 functions. It associates a list of IPv6 address prefixes 1572 with a transit network link by referencing a network- 1573 LSA, or associates a list of IPv6 address prefixes with 1574 a router by referencing a router-LSA. A stub link's 1575 prefixes are associated with its attached router. 1577 A router may originate multiple intra-area-prefix-LSAs 1578 for a given area, distinguished by their Link State ID 1579 fields. 1581 A link's Designated Router originates an intra-area- 1582 prefix-LSA to advertise the link's prefixes throughout 1583 the area. For a link L, L's Designated Router builds an 1584 intra-area-prefix-LSA in the following fashion: 1586 o In order to indicate that the prefixes are to be 1587 associated with the Link L, the fields Referenced LS 1588 type, Referenced Link State ID, and Referenced 1589 Advertising Router are set to the corresponding 1590 fields in Link L's network-LSA (namely LS type, Link 1591 State ID, and Advertising Router respectively). This 1592 means that Referenced LS Type is set to 0x2002, 1593 Referenced Link State ID is set to the Designated 1594 Router's Interface ID on Link L, and Referenced 1595 Advertising Router is set to the Designated Router's 1596 Router ID. 1598 o Each Link-LSA associated with Link L is examined 1599 (these are in the Designated Router's interface 1600 structure for Link L). If the Link-LSA's Advertising 1601 Router is fully adjacent to the Designated Router, 1602 the list of prefixes in the Link-LSA is copied into 1603 the intra-area-prefix-LSA that is being built. 1604 Prefixes having the NU-bit and/or LA-bit set in 1605 their Options field should not be copied, nor should 1606 link-local addresses be copied. Each prefix is 1607 described by the PrefixLength, PrefixOptions, and 1608 Address Prefix fields. Multiple prefixes having the 1609 same PrefixLength and Address Prefix are considered 1610 to be duplicates; in this case their Prefix Options 1611 fields should be merged by logically OR'ing the 1612 fields together, and a single resulting prefix 1613 should be copied into the intra-area-prefix-LSA. The 1614 Metric field for all prefixes is set to 0. 1616 o The "# prefixes" field is set to the number of 1617 prefixes that the router has copied into the LSA. If 1618 necessary, the list of prefixes can be spread across 1619 multiple intra-area-prefix-LSAs in order to keep the 1620 LSA size small. 1622 A router builds an intra-area-prefix-LSA to advertise 1623 its own prefixes, and those of its attached stub links. 1624 A Router RTX would build its intra-area-prefix-LSA in 1625 the following fashion: 1627 o In order to indicate that the prefixes are to be 1628 associated with the Router RTX itself, RTX sets 1629 Referenced LS type to 0x2001, Referenced Link State 1630 ID to 0, and Referenced Advertising Router to RTX's 1631 own Router ID. 1633 o Router RTX examines its list of interfaces to the 1634 area. If the interface is in state Down, its 1635 prefixes are not included. If the interface has been 1636 reported in RTX's router-LSA as a Type 2 link 1637 description (link to transit network), its prefixes 1638 are not included (they will be included in the 1639 intra-area-prefix-LSA for the link instead). If the 1640 interface type is point-to-point or Point-to- 1641 MultiPoint, or the interface is in state Loopback, 1642 the site-local and global scope IPv6 addresses 1643 associated with the interface (if any) are copied 1644 into the intra-area-prefix-LSA, setting the LA-bit 1645 in the PrefixOptions field, and setting the 1646 PrefixLength to 128 and the Metric to 0. Otherwise, 1647 the list of site-local and global prefixes 1648 configured in RTX for the link are copied into the 1649 intra-area-prefix-LSA by specifying the 1650 PrefixLength, PrefixOptions, and Address Prefix 1651 fields. The Metric field for each of these prefixes 1652 is set to the interface's output cost. 1654 o RTX adds the IPv6 prefixes for any directly attached 1655 hosts (see Section C.7) to the intra-area-prefix- 1656 LSA. 1658 o If RTX has one or more virtual links configured 1659 through the area, it includes one of its site-local 1660 or global scope IPv6 interface addresses in the LSA 1661 (if it hasn't already), setting the LA-bit in the 1662 PrefixOptions field, and setting the PrefixLength to 1663 128 and the Metric to 0. This information will be 1664 used later in the routing calculation so that the 1665 two ends of the virtual link can discover each 1666 other's IPv6 addresses. 1668 o The "# prefixes" field is set to the number of 1669 prefixes that the router has copied into the LSA. If 1670 necessary, the list of prefixes can be spread across 1671 multiple intra-area-prefix-LSAs in order to keep the 1672 LSA size small. 1674 For example, the intra-area-prefix-LSA originated by RT4 1675 for Network N3 (assuming that RT4 is N3's Designated 1676 Router), and the intra-area-prefix-LSA originated into 1677 Area 1 by Router RT3 for its own prefixes, are pictured 1678 below. 1680 ; Intra-area-prefix-LSA 1681 ; for network link N3 1683 LS age = 0 ;newly (re)originated 1684 LS type = 0x2009 ;Intra-area-prefix-LSA 1685 Link State ID = 5 ;or something 1686 Advertising Router = 192.1.1.4 ;RT4's Router ID 1687 # prefixes = 1 1688 Referenced LS type = 0x2002 ;network-LSA reference 1689 Referenced Link State ID = 1 1690 Referenced Advertising Router = 192.1.1.4 1691 PrefixLength = 56 ;N3's prefix 1692 PrefixOptions = 0 1693 Metric = 0 1694 Address Prefix = 5f00:0000:c001:0100 ;pad 1696 ; RT3's Intra-area-prefix-LSA 1697 ; for its own prefixes 1699 LS age = 0 ;newly (re)originated 1700 LS type = 0x2009 ;Intra-area-prefix-LSA 1701 Link State ID = 177 ;or something 1702 Advertising Router = 192.1.1.3 ;RT3's Router ID 1703 # prefixes = 1 1704 Referenced LS type = 0x2001 ;router-LSA reference 1705 Referenced Link State ID = 0 1706 Referenced Advertising Router = 192.1.1.3 1707 PrefixLength = 56 ;N4's prefix 1708 PrefixOptions = 0 1709 Metric = 2 ;N4 interface cost 1710 Address Prefix = 5f00:0000:c001:0400 ;pad 1712 Note that in the intra-area-prefix-LSA, the "Referenced 1713 Advertising Router" is always equal to the router that 1714 is originating the intra-area-prefix-LSA (i.e., the 1715 LSA's Advertising Router). The reason that the 1716 Referenced Advertising Router field appears is that, 1717 even though it is currently redundant, it may not be in 1718 the future. We may sometime want to use the same LSA 1719 format to advertise address prefixes for other protocol 1720 suites. In that event, the Designated Router may not be 1721 running the other protocol suite, and so another of the 1722 link's routers may need to send out the prefix-LSA. In 1723 that case, "Referenced Advertising Router" and 1724 "Advertising Router" would be different. 1726 3.5. Flooding 1728 Most of the flooding algorithm remains unchanged from the IPv4 1729 flooding mechanisms described in Section 13 of [Ref1]. In 1730 particular, the processes for determining which LSA instance is 1731 newer (Section 13.1 of [Ref1]), responding to updates of self- 1732 originated LSAs (Section 13.4 of [Ref1]), sending Link State 1733 Acknowledgment packets (Section 13.5 of [Ref1]), retransmitting 1734 LSAs (Section 13.6 of [Ref1]) and receiving Link State 1735 Acknowledgment packets (Section 13.7 of [Ref1]) are exactly the 1736 same for IPv6 and IPv4. 1738 However, the addition of flooding scope and handling options for 1739 unrecognized LSA types (see Section A.4.2.1) has caused some 1740 changes in the OSPF flooding algorithm: the reception of Link 1741 State Updates (Section 13 in [Ref1]) and the sending of Link 1742 State Updates (Section 13.3 of [Ref1]) must take into account 1743 the LSA's scope and U-bit setting. Also, installation of LSAs 1744 into the OSPF database (Section 13.2 of [Ref1]) causes different 1745 events in IPv6, due to the reorganization of LSA types and 1746 contents in IPv6. These changes are described in detail below. 1748 3.5.1. Receiving Link State Update packets 1750 The encoding of flooding scope in the LS type and the need 1751 to process unknown LS types causes modifications to the 1752 processing of received Link State Update packets. As in 1753 IPv4, each LSA in a received Link State Update packet is 1754 examined. In IPv4, eight steps are executed for each LSA, as 1755 described in Section 13 of [Ref1]. For IPv6, all the steps 1756 are the same, except that Steps 2 and 3 are modified as 1757 follows: 1759 (2) Examine the LSA's LS type. If the LS type is unknown, 1760 the area has been configured as a stub area, and either 1761 the LSA's flooding scope is set to "AS flooding scope" 1762 or the U-bit of the LS type is set to 1 (flood even when 1763 unrecognized), then discard the LSA and get the next one 1764 from the Link State Update Packet. This generalizes the 1765 IPv4 behavior where AS-external-LSAs are not flooded 1766 into/throughout stub areas. 1768 (3) Else if the flooding scope of the LSA is set to 1769 "reserved", discard the LSA and get the next one from 1770 the Link State Update Packet. 1772 Steps 5b (sending Link State Update packets) and 5d 1773 (installing LSAs in the link state database) in Section 13 1774 of [Ref1] are also somewhat different for IPv6, as described 1775 in Sections 3.5.2 and 3.5.3 below. 1777 3.5.2. Sending Link State Update packets 1779 The sending of Link State Update packets is described in 1780 Section 13.3 of [Ref1]. For IPv4 and IPv6, the steps for 1781 sending a Link State Update packet are the same (steps 1 1782 through 5 of Section 13.3 in [Ref1]). However, the list of 1783 eligible interfaces out which to flood the LSA is different. 1784 For IPv6, the eligible interfaces are selected based on the 1785 following factors: 1787 o The LSA's flooding scope. 1789 o For LSAs with area or link-local flooding scoping, the 1790 particular area or interface that the LSA is associated 1791 with. 1793 o Whether the LSA has a recognized LS type. 1795 o The setting of the U-bit in the LS type. If the U-bit is 1796 set to 0, unrecognized LS types are treated as having 1797 link-local scope. If set to 1, unrecognized LS types are 1798 stored and flooded as if they were recognized. 1800 Choosing the set of eligible interfaces then breaks into the 1801 following cases: 1803 Case 1 1804 The LSA's LS type is recognized. In this case, the set 1805 of eligible interfaces is set depending on the flooding 1806 scope encoded in the LS type. If the flooding scope is 1807 "AS flooding scope", the eligible interfaces are all 1808 router interfaces excepting virtual links. In addition, 1809 AS-external-LSAs are not flooded out interfaces 1810 connecting to stub areas. If the flooding scope is "area 1811 flooding scope", the set of eligible interfaces are 1812 those interfaces connecting to the LSA's associated 1813 area. If the flooding scope is "link-local flooding 1814 scope", then there is a single eligible interface, the 1815 one connecting to the LSA's associated link (which, when 1816 the LSA is received in a Link State Update packet, is 1817 also the interface the LSA was received on). 1819 Case 2 1820 The LS type is unrecognized, and the U-bit in the LS 1821 Type is set to 0 (treat the LSA as if it had link-local 1822 flooding scope). In this case there is a single eligible 1823 interface, namely, the interface on which the LSA was 1824 received. 1826 Case 3 1827 The LS type is unrecognized, and the U-bit in the LS 1828 Type is set to 1 (store and flood the LSA, as if type 1829 understood). In this case, select the eligible 1830 interfaces based on the encoded flooding scope as in 1831 Case 1 above. However, in this case interfaces attached 1832 to stub areas are always excluded. 1834 A further decision must sometimes be made before adding an 1835 LSA to a given neighbor's link-state retransmission list 1836 (Step 1d in Section 13.3 of [Ref1]). If the LS type is 1837 recognized by the router, but not by the neighbor (as can be 1838 determined by examining the Options field that the neighbor 1839 advertised in its Database Description packet) and the LSA's 1840 U-bit is set to 0, then the LSA should be added to the 1841 neighbor's link-state retransmission list if and only if 1842 that neighbor is the Designated Router or Backup Designated 1843 Router for the attached link. The LS types described in 1844 detail by this memo, namely router-LSAs (LS type 0x2001), 1845 network-LSAs (0x2002), Inter-Area-Prefix-LSAs (0x2003), 1846 Inter-Area-Router-LSAs (0x2004), AS-External-LSAs (0x4005), 1847 Link-LSAs (0x0008) and Intra-Area-Prefix-LSAs (0x2009) are 1848 assumed to be understood by all routers. However, as an 1849 example the group-membership-LSA (0x2006) is understood only 1850 by MOSPF routers and since it has its U-bit set to 0, it 1851 should only be forwarded to a non-MOSPF neighbor (determined 1852 by examining the MC-bit in the neighbor's Database 1853 Description packets' Options field) when the neighbor is 1854 Designated Router or Backup Designated Router for the 1855 attached link. 1857 The previous paragraph solves a problem in IPv4 OSPF 1858 extensions such as MOSPF, which require that the Designated 1859 Router support the extension in order to have the new LSA 1860 types flooded across broadcast and NBMA networks (see 1861 Section 10.2 of [Ref8]). 1863 3.5.3. Installing LSAs in the database 1865 There are three separate places to store LSAs, depending on 1866 their flooding scope. LSAs with AS flooding scope are stored 1867 in the global OSPF data structure (see Section 3.1) as long 1868 as their LS type is known or their U-bit is 1. LSAs with 1869 area flooding scope are stored in the appropriate area data 1870 structure (see Section 3.1.1) as long as their LS type is 1871 known or their U-bit is 1. LSAs with link-local flooding 1872 scope, and those LSAs with unknown LS type and U-bit set to 1873 0 (treat the LSA as if it had link-local flooding scope) are 1874 stored in the appropriate interface structure. 1876 When storing the LSA into the link-state database, a check 1877 must be made to see whether the LSA's contents have changed. 1878 Changes in contents are indicated exactly as in Section 13.2 1879 of [Ref1]. When an LSA's contents have been changed, the 1880 following parts of the routing table must be recalculated, 1881 based on the LSA's LS type: 1883 Router-LSAs, Network-LSAs and Intra-Area-Prefix-LSAs 1884 The entire routing table is recalculated, starting with 1885 the shortest path calculation for each area (see Section 1886 3.8). 1888 Link-LSAs 1889 The next hop of some of the routing table's entries, 1890 which is always an IPv6 link-local address, may need to 1891 be recalculated. Link-local LSAs provide the OSPF Router 1892 ID to link-local address mapping used in the next hop 1893 calculation. See Section 3.8.1.1 for details. 1895 Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs 1896 The best route to the destination described by the LSA 1897 must be recalculated (see Section 16.5 in [Ref1]). If 1898 this destination is an AS boundary router, it may also 1899 be necessary to re-examine all the AS-external-LSAs. 1901 AS-external-LSAs 1902 The best route to the destination described by the AS- 1903 external-LSA must be recalculated (see Section 16.6 in 1904 [Ref1]). 1906 As in IPv4, any old instance of the LSA must be removed from 1907 the database when the new LSA is installed. This old 1908 instance must also be removed from all neighbors' Link state 1909 retransmission lists. 1911 3.6. Definition of self-originated LSAs 1913 In IPv6 the definition of a self-originated LSA has been 1914 simplified from the IPv4 definition appearing in Sections 13.4 1915 and 14.1 of [Ref1]. For IPv6, self-originated LSAs are those 1916 LSAs whose Advertising Router is equal to the router's own 1917 Router ID. 1919 3.7. Virtual links 1921 OSPF virtual links for IPv4 are described in Section 15 of 1922 [Ref1]. Virtual links are the same in IPv6, with the following 1923 exceptions: 1925 o LSAs having AS flooding scope are never flooded over virtual 1926 adjacencies, nor are LSAs with AS flooding scope summarized 1927 over virtual adjacencies during the Database Exchange 1928 process. This is a generalization of the IPv4 treatment of 1929 AS-external-LSAs. 1931 o The IPv6 interface address of a virtual link must be an IPv6 1932 address having site-local or global scope, instead of the 1933 link-local addresses used by other interface types. This 1934 address is used as the IPv6 source for OSPF protocol packets 1935 sent over the virtual link. 1937 o Likewise, the virtual neighbor's IPv6 address is an IPv6 1938 address with site-local or global scope. To enable the 1939 discovery of a virtual neighbor's IPv6 address during the 1940 routing calculation, the neighbor advertises its virtual 1941 link's IPv6 interface address in an Intra-Area-Prefix-LSA 1942 originated for the virtual link's transit area (see Sections 1943 3.4.3.7 and 3.8.1). 1945 o Like all other IPv6 OSPF interfaces, virtual links are 1946 assigned unique (within the router) Interface IDs. These are 1947 advertised in Hellos sent over the virtual link, and in the 1948 router's router-LSAs. 1950 3.8. Routing table calculation 1952 The IPv6 OSPF routing calculation proceeds along the same lines 1953 as the IPv4 OSPF routing calculation, following the five steps 1954 specified by Section 16 of [Ref1]. High level differences 1955 between the IPv6 and IPv4 calculations include: 1957 o Prefix information has been removed from router-LSAs, and 1958 now is advertised in intra-area-prefix-LSAs. Whenever [Ref1] 1959 specifies that stub networks within router-LSAs be examined, 1960 IPv6 will instead examine prefixes within intra-area- 1961 prefix-LSAs. 1963 o Type 3 and 4 summary-LSAs have been renamed inter-area- 1964 prefix-LSAs and inter-area-router-LSAs (respectively). 1966 o Addressing information is no longer encoded in Link State 1967 IDs, and must instead be found within the body of LSAs. 1969 o In IPv6, a router can originate multiple router-LSAs within 1970 a single area, distinguished by Link State ID. These 1971 router-LSAs must be treated as a single aggregate by the 1972 area's shortest path calculation (see Section 3.8.1). 1974 For each area, routing table entries have been created for the 1975 area's routers and transit links, in order to store the results 1976 of the area's shortest-path tree calculation (see Section 1977 3.8.1). These entries are then used when processing intra-area- 1978 prefix-LSAs, inter-area-prefix-LSAs and inter-area-router-LSAs, 1979 as described in Section 3.8.2. 1981 Events generated as a result of routing table changes (Section 1982 16.7 of [Ref1]), and the equal-cost multipath logic (Section 1983 16.8 of [Ref1]) are identical for both IPv4 and IPv6. 1985 3.8.1. Calculating the shortest path tree for an area 1987 The IPv4 shortest path calculation is contained in Section 1988 16.1 of [Ref1]. The graph used by the shortest-path tree 1989 calculation is identical for both IPv4 and IPv6. The graph's 1990 vertices are routers and transit links, represented by 1991 router-LSAs and network-LSAs respectively. A router is 1992 identified by its OSPF Router ID, while a transit link is 1993 identified by its Designated Router's Interface ID and OSPF 1994 Router ID. Both routers and transit links have associated 1995 routing table entries within the area (see Section 3.3). 1997 Section 16.1 of [Ref1] splits up the shortest path 1998 calculations into two stages. First the Dijkstra calculation 1999 is performed, and then the stub links are added onto the 2000 tree as leaves. The IPv6 calculation maintains this split. 2002 The Dijkstra calculation for IPv6 is identical to that 2003 specified for IPv4, with the following exceptions 2004 (referencing the steps from the Dijkstra calculation as 2005 described in Section 16.1 of [Ref1]): 2007 o The Vertex ID for a router is the OSPF Router ID. The 2008 Vertex ID for a transit network is a combination of the 2009 Interface ID and OSPF Router ID of the network's 2010 Designated Router. 2012 o In Step 2, when a router Vertex V has just been added to 2013 the shortest path tree, there may be multiple LSAs 2014 associated with the router. All Router-LSAs with 2015 Advertising Router set to V's OSPF Router ID must 2016 processed as an aggregate, treating them as fragments of 2017 a single large router-LSA. The Options field and the 2018 router type bits (bits W, V, E and B) should always be 2019 taken from "fragment" with the smallest Link State ID. 2021 o Step 2a is not needed in IPv6, as there are no longer 2022 stub network links in router-LSAs. 2024 o In Step 2b, if W is a router, there may again be 2025 multiple LSAs associated with the router. All Router- 2026 LSAs with Advertising Router set to W's OSPF Router ID 2027 must processed as an aggregate, treating them as 2028 fragments of a single large router-LSA. 2030 o In Step 4, there are now per-area routing table entries 2031 for each of an area's routers, instead of just the area 2032 border routers. These entries subsume all the 2033 functionality of IPv4's area border router routing table 2034 entries, including the maintenance of virtual links. 2035 When the router added to the area routing table in this 2036 step is the other end of a virtual link, the virtual 2037 neighbor's IP address is set as follows: The collection 2038 of intra-area-prefix-LSAs originated by the virtual 2039 neighbor is examined, with the virtual neighbor's IP 2040 address being set to the first prefix encountered having 2041 the "LA-bit" set. 2043 o Routing table entries for transit networks, which are no 2044 longer associated with IP networks, are also modified in 2045 Step 4. 2047 The next stage of the shortest path calculation proceeds 2048 similarly to the two steps of the second stage of Section 2049 16.1 in [Ref1]. However, instead of examining the stub links 2050 within router-LSAs, the list of the area's intra-area- 2051 prefix-LSAs is examined. A prefix advertisement whose "NU- 2052 bit" is set should not be included in the routing 2053 calculation. The cost of any advertised prefix is the sum of 2054 the prefix' advertised metric plus the cost to the transit 2055 vertex (either router or transit network) identified by 2056 intra-area-prefix-LSA's Referenced LS type, Referenced Link 2057 State ID and Referenced Advertising Router fields. This 2058 latter cost is stored in the transit vertex' routing table 2059 entry for the area. 2061 3.8.1.1. The next hop calculation 2063 In IPv6, the calculation of the next hop's IPv6 address 2064 (which will be a link-local address) proceeds along the 2065 same lines as the IPv4 next hop calculation (see Section 2066 16.1.1 of [Ref1]). The only difference is in calculating 2067 the next hop IPv6 address for a router (call it Router 2068 X) which shares a link with the calculating router. In 2069 this case the calculating router assigns the next hop 2070 IPv6 address to be the link-local interface address 2071 contained in Router X's Link-LSA (see Section A.4.8) for 2072 the link. This procedure is necessary since on some 2073 links, such as NBMA links, the two routers need not be 2074 neighbors, and therefore might not be exchanging OSPF 2075 Hellos. 2077 3.8.2. Calculating the inter-area routes 2079 Calculation of inter-area routes for IPv6 proceeds along the 2080 same lines as the IPv4 calculation in Section 16.2 of 2081 [Ref1], with the following modifications: 2083 o The names of the Type 3 summary-LSAs and Type 4 2084 summary-LSAs have been changed to inter-area-prefix-LSAs 2085 and inter-area-router-LSAs respectively. 2087 o The Link State ID of the above LSA types no longer 2088 encodes the network or router described by the LSA. 2089 Instead, an address prefix is contained in the body of 2090 an inter-area-prefix-LSA, and a described router's OSPF 2091 Router ID is carried in the body of an inter-area- 2092 router-LSA. 2094 o Prefixes having the "NU-bit" set in their Prefix Options 2095 field should be ignored by the inter-area route 2096 calculation. 2098 When a single inter-area-prefix-LSA or inter-area-router-LSA 2099 has changed, the incremental calculations outlined in 2100 Section 16.5 of [Ref1] can be performed instead of 2101 recalculating the entire routing table. 2103 3.8.3. Examining transit areas' summary-LSAs 2105 Examination of transit areas' summary-LSAs in IPv6 proceeds 2106 along the same lines as the IPv4 calculation in Section 16.3 2107 of [Ref1], modified in the same way as the IPv6 inter-area 2108 route calculation in Section 3.8.2. 2110 3.8.4. Calculating AS external routes 2112 The IPv6 AS external route calculation proceeds along the 2113 same lines as the IPv4 calculation in Section 16.4 of 2114 [Ref1], with the following exceptions: 2116 o The Link State ID of the AS-external-LSA types no longer 2117 encodes the network described by the LSA. Instead, an 2118 address prefix is contained in the body of an AS- 2119 external-LSA. 2121 o The default route is described by AS-external-LSAs which 2122 advertise zero length prefixes. 2124 o Instead of comparing the AS-external-LSA's Forwarding 2125 address field to 0.0.0.0 to see whether a forwarding 2126 address has been used, bit F of the external-LSA is 2127 examined. A forwarding address is in use if and only if 2128 bit F is set. 2130 o Prefixes having the "NU-bit" set in their Prefix Options 2131 field should be ignored by the inter-area route 2132 calculation. 2134 When a single AS-external-LSA has changed, the incremental 2135 calculations outlined in Section 16.6 of [Ref1] can be 2136 performed instead of recalculating the entire routing table. 2138 3.9. Multiple interfaces to a single link 2140 In OSPF for IPv6, a router may have multiple interfaces to a 2141 single link. All interfaces are involved in the reception and 2142 transmission of data traffic, however only a single interface 2143 sends and receives OSPF control traffic. In more detail: 2145 o Each of the multiple interfaces are assigned different 2146 Interface IDs. In this way the router can automatically 2147 detect when multiple interfaces attach to the same link, 2148 when receiving Hellos from its own Router ID but with an 2149 Interface ID other than the receiving interface's. 2151 o The router turns off the sending and receiving of OSPF 2152 packets (that is, control traffic) on all but one of the 2153 interfaces to the link. The choice of interface to send and 2154 receive control traffic is implementation dependent; as one 2155 example, the interface with the highest Interface ID could 2156 be chosen. If the router is elected DR, it will be this 2157 interface's Interface ID that will be used as the network- 2158 LSA's Link State ID. 2160 o All the multiple interfaces to the link will however appear 2161 in the router-LSA. In addition, a Link-LSA will be generated 2162 for each of the multiple interfaces. In this way, all 2163 interfaces will be included in OSPF's routing calculations. 2165 o If the interface which is responsible for sending and 2166 receiving control traffic fails, another will have to take 2167 over, reforming all neighbor adjacencies from scratch. This 2168 failure can be detected by the router itself, when the other 2169 interfaces to the same link cease to hear the router's own 2170 Hellos. 2172 References 2174 [Ref1] Moy, J., "OSPF Version 2", Internet Draft, , Ascend, November 1997. 2177 [Ref2] McKenzie, A., "ISO Transport Protocol specification ISO DP 2178 8073", RFC 905, ISO, April 1984. 2180 [Ref3] McCloghrie, K., and M. Rose, "Management Information Base 2181 for network management of TCP/IP-based internets: MIB-II", 2182 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 2183 International, March 1991. 2185 [Ref4] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 2186 Inter-Domain Routing (CIDR): an Address Assignment and 2187 Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, 2188 OARnet, September 1993. 2190 [Ref5] Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP--- 2191 OSPF Interaction", RFC1745, December 1994 2193 [Ref6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 2194 1700, USC/Information Sciences Institute, October 1994. 2196 [Ref7] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 2197 Over Frame Relay Networks", RFC 1586, March 1994. 2199 [Ref8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 2200 Inc., March 1994. 2202 [Ref9] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 2203 RainbowBridge Communications, Stanford University, March 2204 1994. 2206 [Ref10] Ferguson, D., "The OSPF External Attributes LSA", 2207 unpublished. 2209 [Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 2210 1793, Cascade, April 1995. 2212 [Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 2213 DECWRL, Stanford University, November 1990. 2215 [Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 2216 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco 2217 Systems, March 1995. 2219 [Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2220 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon 2221 Networks, December 1995. 2223 [Ref15] Deering, S. and R. Hinden, "IP Version 6 Addressing 2224 Architecture", RFC 1884, Xerox PARC, Ipsilon Networks, 2225 December 1995. 2227 [Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol 2228 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2229 Specification" RFC 1885, Digital Equipment Corporation, 2230 Xerox PARC, December 1995. 2232 [Ref17] Narten, T., E. Nordmark and W. Simpson, "Neighbor Discovery 2233 for IP Version 6 (IPv6)", RFC 1970, August 1996. 2235 [Ref18] McCann, J., S. Deering and J. Mogul, "Path MTU Discovery for 2236 IP version 6", RFC 1981, August 1996. 2238 [Ref19] Atkinson, R., "IP Authentication Header", RFC 1826, Naval 2239 Research Laboratory, August 1995. 2241 [Ref20] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2242 1827, Naval Research Laboratory, August 1995. 2244 A. OSPF data formats 2246 This appendix describes the format of OSPF protocol packets and OSPF 2247 LSAs. The OSPF protocol runs directly over the IPv6 network layer. 2248 Before any data formats are described, the details of the OSPF 2249 encapsulation are explained. 2251 Next the OSPF Options field is described. This field describes 2252 various capabilities that may or may not be supported by pieces of 2253 the OSPF routing domain. The OSPF Options field is contained in OSPF 2254 Hello packets, Database Description packets and in OSPF LSAs. 2256 OSPF packet formats are detailed in Section A.3. 2258 A description of OSPF LSAs appears in Section A.4. This section 2259 describes how IPv6 address prefixes are represented within LSAs, 2260 details the standard LSA header, and then provides formats for each 2261 of the specific LSA types. 2263 A.1 Encapsulation of OSPF packets 2265 OSPF runs directly over the IPv6's network layer. OSPF packets are 2266 therefore encapsulated solely by IPv6 and local data-link headers. 2268 OSPF does not define a way to fragment its protocol packets, and 2269 depends on IPv6 fragmentation when transmitting packets larger than 2270 the link MTU. If necessary, the length of OSPF packets can be up to 2271 65,535 bytes. The OSPF packet types that are likely to be large 2272 (Database Description Packets, Link State Request, Link State 2273 Update, and Link State Acknowledgment packets) can usually be split 2274 into several separate protocol packets, without loss of 2275 functionality. This is recommended; IPv6 fragmentation should be 2276 avoided whenever possible. Using this reasoning, an attempt should 2277 be made to limit the sizes of OSPF packets sent over virtual links 2278 to 576 bytes unless Path MTU Discovery is being performed. 2280 The other important features of OSPF's IPv6 encapsulation are: 2282 o Use of IPv6 multicast. Some OSPF messages are multicast, when 2283 sent over broadcast networks. Two distinct IP multicast 2284 addresses are used. Packets sent to these multicast addresses 2285 should never be forwarded; they are meant to travel a single hop 2286 only. As such, the multicast addresses have been chosen with 2287 link-local scope, and packets sent to these addresses should 2288 have their IPv6 Hop Limit set to 1. 2290 AllSPFRouters 2291 This multicast address has been assigned the value FF02::5. 2293 All routers running OSPF should be prepared to receive 2294 packets sent to this address. Hello packets are always sent 2295 to this destination. Also, certain OSPF protocol packets 2296 are sent to this address during the flooding procedure. 2298 AllDRouters 2299 This multicast address has been assigned the value FF02::6. 2300 Both the Designated Router and Backup Designated Router must 2301 be prepared to receive packets destined to this address. 2302 Certain OSPF protocol packets are sent to this address 2303 during the flooding procedure. 2305 o OSPF is IP protocol 89. This number should be inserted in the 2306 Next Header field of the encapsulating IPv6 header. 2308 A.2 The Options field 2310 The 24-bit OSPF Options field is present in OSPF Hello packets, 2311 Database Description packets and certain LSAs (router-LSAs, 2312 network-LSAs, inter-area-router-LSAs and link-LSAs). The Options 2313 field enables OSPF routers to support (or not support) optional 2314 capabilities, and to communicate their capability level to other 2315 OSPF routers. Through this mechanism routers of differing 2316 capabilities can be mixed within an OSPF routing domain. 2318 An option mismatch between routers can cause a variety of behaviors, 2319 depending on the particular option. Some option mismatches prevent 2320 neighbor relationships from forming (e.g., the E-bit below); these 2321 mismatches are discovered through the sending and receiving of Hello 2322 packets. Some option mismatches prevent particular LSA types from 2323 being flooded across adjacencies (e.g., the MC-bit below); these are 2324 discovered through the sending and receiving of Database Description 2325 packets. Some option mismatches prevent routers from being included 2326 in one or more of the various routing calculations because of their 2327 reduced functionality (again the MC-bit is an example); these 2328 mismatches are discovered by examining LSAs. 2330 Six bits of the OSPF Options field have been assigned. Each bit is 2331 described briefly below. Routers should reset (i.e. clear) 2332 unrecognized bits in the Options field when sending Hello packets or 2333 Database Description packets and when originating LSAs. Conversely, 2334 routers encountering unrecognized Option bits in received Hello 2335 Packets, Database Description packets or LSAs should ignore the 2336 capability and process the packet/LSA normally. 2338 1 2 2339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 2341 | | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6| 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 2344 The Options field 2346 V6-bit 2347 If this bit is clear, the router/link should be excluded from 2348 IPv6 routing calculations. See Section 3.8 of this memo. 2350 E-bit 2351 This bit describes the way AS-external-LSAs are flooded, as 2352 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [Ref1]. 2354 MC-bit 2355 This bit describes whether IP multicast datagrams are forwarded 2356 according to the specifications in [Ref7]. 2358 N-bit 2359 This bit describes the handling of Type-7 LSAs, as specified in 2360 [Ref8]. 2362 R-bit 2363 This bit (the `Router' bit) indicates whether the originator is 2364 an active router. If the router bit is clear routes which 2365 transit the advertising node cannot be computed. Clearing the 2366 router bit would be appropriate for a multi-homed host that 2367 wants to participate in routing, but does not want to forward 2368 non-locally addressed packets. 2370 DC-bit 2371 This bit describes the router's handling of demand circuits, as 2372 specified in [Ref10]. 2374 A.3 OSPF Packet Formats 2376 There are five distinct OSPF packet types. All OSPF packet types 2377 begin with a standard 16 byte header. This header is described 2378 first. Each packet type is then described in a succeeding section. 2379 In these sections each packet's division into fields is displayed, 2380 and then the field definitions are enumerated. 2382 All OSPF packet types (other than the OSPF Hello packets) deal with 2383 lists of LSAs. For example, Link State Update packets implement the 2384 flooding of LSAs throughout the OSPF routing domain. The format of 2385 LSAs is described in Section A.4. 2387 The receive processing of OSPF packets is detailed in Section 3.2.2. 2388 The sending of OSPF packets is explained in Section 3.2.1. 2390 A.3.1 The OSPF packet header 2392 Every OSPF packet starts with a standard 16 byte header. Together 2393 with the encapsulating IPv6 headers, the OSPF header contains all 2394 the information necessary to determine whether the packet should be 2395 accepted for further processing. This determination is described in 2396 Section 3.2.2 of this memo. 2398 0 1 2 3 2399 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 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Version # | Type | Packet length | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | Router ID | 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 | Area ID | 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 | Checksum | Instance ID | 0 | 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2410 Version # 2411 The OSPF version number. This specification documents version 3 2412 of the OSPF protocol. 2414 Type 2415 The OSPF packet types are as follows. See Sections A.3.2 through 2416 A.3.6 for details. 2418 Type Description 2419 ________________________________ 2420 1 Hello 2421 2 Database Description 2422 3 Link State Request 2423 4 Link State Update 2424 5 Link State Acknowledgment 2426 Packet length 2427 The length of the OSPF protocol packet in bytes. This length 2428 includes the standard OSPF header. 2430 Router ID 2431 The Router ID of the packet's source. 2433 Area ID 2434 A 32 bit number identifying the area that this packet belongs 2435 to. All OSPF packets are associated with a single area. Most 2436 travel a single hop only. Packets travelling over a virtual 2437 link are labelled with the backbone Area ID of 0. 2439 Checksum 2440 OSPF uses the standard checksum calculation for IPv6 2441 applications: The 16-bit one's complement of the one's 2442 complement sum of the entire contents of the packet, starting 2443 with the OSPF packet header, and prepending a "pseudo-header" of 2444 IPv6 header fields, as specified in [Ref14, section 8.1]. The 2445 Next Header value used in the pseudo-header is 89. If the 2446 packet's length is not an integral number of 16-bit words, the 2447 packet is padded with a byte of zero before checksumming. Before 2448 computing the checksum, the checksum field in the OSPF packet 2449 header is set to 0. 2451 Instance ID 2452 Enables multiple instances of OSPF to be run over a single link. 2453 Each protocol instance would be assigned a separate Instance ID; 2454 the Instance ID has local link significance only. Received 2455 packets whose Instance ID is not equal to the receiving 2456 interface's Instance ID are discarded. 2458 0 These fields are reserved. They must be 0. 2460 A.3.2 The Hello packet 2462 Hello packets are OSPF packet type 1. These packets are sent 2463 periodically on all interfaces (including virtual links) in order to 2464 establish and maintain neighbor relationships. In addition, Hello 2465 Packets are multicast on those links having a multicast or broadcast 2466 capability, enabling dynamic discovery of neighboring routers. 2468 All routers connected to a common link must agree on certain 2469 parameters (HelloInterval and RouterDeadInterval). These parameters 2470 are included in Hello packets, so that differences can inhibit the 2471 forming of neighbor relationships. The Hello packet also contains 2472 fields used in Designated Router election (Designated Router ID and 2473 Backup Designated Router ID), and fields used to detect bi- 2474 directionality (the Router IDs of all neighbors whose Hellos have 2475 been recently received). 2477 0 1 2 3 2478 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 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 | 3 | 1 | Packet length | 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | Router ID | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 | Area ID | 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 | Checksum | Instance ID | 0 | 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 | Interface ID | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 | Rtr Pri | Options | 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 | HelloInterval | RouterDeadInterval | 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | Designated Router ID | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 | Backup Designated Router ID | 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 | Neighbor ID | 2499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2500 | ... | 2502 Interface ID 2503 32-bit number uniquely identifying this interface among the 2504 collection of this router's interfaces. For example, in some 2505 implementations it may be possible to use the MIB-II IfIndex. 2507 Rtr Pri 2508 This router's Router Priority. Used in (Backup) Designated 2509 Router election. If set to 0, the router will be ineligible to 2510 become (Backup) Designated Router. 2512 Options 2513 The optional capabilities supported by the router, as documented 2514 in Section A.2. 2516 HelloInterval 2517 The number of seconds between this router's Hello packets. 2519 RouterDeadInterval 2520 The number of seconds before declaring a silent router down. 2522 Designated Router ID 2523 The identity of the Designated Router for this network, in the 2524 view of the sending router. The Designated Router is identified 2525 by its Router ID. Set to 0.0.0.0 if there is no Designated 2526 Router. 2528 Backup Designated Router ID 2529 The identity of the Backup Designated Router for this network, 2530 in the view of the sending router. The Backup Designated Router 2531 is identified by its IP Router ID. Set to 0.0.0.0 if there is 2532 no Backup Designated Router. 2534 Neighbor ID 2535 The Router IDs of each router from whom valid Hello packets have 2536 been seen recently on the network. Recently means in the last 2537 RouterDeadInterval seconds. 2539 A.3.3 The Database Description packet 2541 Database Description packets are OSPF packet type 2. These packets 2542 are exchanged when an adjacency is being initialized. They describe 2543 the contents of the link-state database. Multiple packets may be 2544 used to describe the database. For this purpose a poll-response 2545 procedure is used. One of the routers is designated to be the 2546 master, the other the slave. The master sends Database Description 2547 packets (polls) which are acknowledged by Database Description 2548 packets sent by the slave (responses). The responses are linked to 2549 the polls via the packets' DD sequence numbers. 2551 0 1 2 3 2552 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 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | 3 | 2 | Packet length | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | Router ID | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | Area ID | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | Checksum | Instance ID | 0 | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | 0 | Options | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | Interface MTU | 0 |0|0|0|0|0|I|M|MS 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | DD sequence number | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | | 2569 +- -+ 2570 | | 2571 +- An LSA Header -+ 2572 | | 2573 +- -+ 2574 | | 2575 +- -+ 2576 | | 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | ... | 2580 The format of the Database Description packet is very similar to 2581 both the Link State Request and Link State Acknowledgment packets. 2582 The main part of all three is a list of items, each item describing 2583 a piece of the link-state database. The sending of Database 2584 Description Packets is documented in Section 10.8 of [Ref1]. The 2585 reception of Database Description packets is documented in Section 2586 10.6 of [Ref1]. 2588 Options 2589 The optional capabilities supported by the router, as documented 2590 in Section A.2. 2592 Interface MTU 2593 The size in bytes of the largest IPv6 datagram that can be sent 2594 out the associated interface, without fragmentation. The MTUs 2595 of common Internet link types can be found in Table 7-1 of 2596 [Ref12]. Interface MTU should be set to 0 in Database 2597 Description packets sent over virtual links. 2599 I-bit 2600 The Init bit. When set to 1, this packet is the first in the 2601 sequence of Database Description Packets. 2603 M-bit 2604 The More bit. When set to 1, it indicates that more Database 2605 Description Packets are to follow. 2607 MS-bit 2608 The Master/Slave bit. When set to 1, it indicates that the 2609 router is the master during the Database Exchange process. 2610 Otherwise, the router is the slave. 2612 DD sequence number 2613 Used to sequence the collection of Database Description Packets. 2614 The initial value (indicated by the Init bit being set) should 2615 be unique. The DD sequence number then increments until the 2616 complete database description has been sent. 2618 The rest of the packet consists of a (possibly partial) list of the 2619 link-state database's pieces. Each LSA in the database is described 2620 by its LSA header. The LSA header is documented in Section A.4.1. 2621 It contains all the information required to uniquely identify both 2622 the LSA and the LSA's current instance. 2624 A.3.4 The Link State Request packet 2626 Link State Request packets are OSPF packet type 3. After exchanging 2627 Database Description packets with a neighboring router, a router may 2628 find that parts of its link-state database are out-of-date. The 2629 Link State Request packet is used to request the pieces of the 2630 neighbor's database that are more up-to-date. Multiple Link State 2631 Request packets may need to be used. 2633 A router that sends a Link State Request packet has in mind the 2634 precise instance of the database pieces it is requesting. Each 2635 instance is defined by its LS sequence number, LS checksum, and LS 2636 age, although these fields are not specified in the Link State 2637 Request Packet itself. The router may receive even more recent 2638 instances in response. 2640 The sending of Link State Request packets is documented in Section 2641 10.9 of [Ref1]. The reception of Link State Request packets is 2642 documented in Section 10.7 of [Ref1]. 2644 0 1 2 3 2645 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 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 | 3 | 3 | Packet length | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 | Router ID | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 | Area ID | 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 | Checksum | Instance ID | 0 | 2654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2655 | 0 | LS type | 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 | Link State ID | 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 | Advertising Router | 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | ... | 2663 Each LSA requested is specified by its LS type, Link State ID, and 2664 Advertising Router. This uniquely identifies the LSA, but not its 2665 instance. Link State Request packets are understood to be requests 2666 for the most recent instance (whatever that might be). 2668 A.3.5 The Link State Update packet 2670 Link State Update packets are OSPF packet type 4. These packets 2671 implement the flooding of LSAs. Each Link State Update packet 2672 carries a collection of LSAs one hop further from their origin. 2673 Several LSAs may be included in a single packet. 2675 Link State Update packets are multicast on those physical networks 2676 that support multicast/broadcast. In order to make the flooding 2677 procedure reliable, flooded LSAs are acknowledged in Link State 2678 Acknowledgment packets. If retransmission of certain LSAs is 2679 necessary, the retransmitted LSAs are always carried by unicast Link 2680 State Update packets. For more information on the reliable flooding 2681 of LSAs, consult Section 3.5. 2683 0 1 2 3 2684 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 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 | 3 | 4 | Packet length | 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 | Router ID | 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | Area ID | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 | Checksum | Instance ID | 0 | 2693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2694 | # LSAs | 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 | | 2697 +- +-+ 2698 | LSAs | 2699 +- +-+ 2700 | ... | 2702 # LSAs 2703 The number of LSAs included in this update. 2705 The body of the Link State Update packet consists of a list of LSAs. 2706 Each LSA begins with a common 20 byte header, described in Section 2707 A.4.2. Detailed formats of the different types of LSAs are described 2708 in Section A.4. 2710 A.3.6 The Link State Acknowledgment packet 2712 Link State Acknowledgment Packets are OSPF packet type 5. To make 2713 the flooding of LSAs reliable, flooded LSAs are explicitly 2714 acknowledged. This acknowledgment is accomplished through the 2715 sending and receiving of Link State Acknowledgment packets. The 2716 sending of Link State Acknowledgement packets is documented in 2717 Section 13.5 of [Ref1]. The reception of Link State Acknowledgement 2718 packets is documented in Section 13.7 of [Ref1]. 2720 Multiple LSAs can be acknowledged in a single Link State 2721 Acknowledgment packet. Depending on the state of the sending 2722 interface and the sender of the corresponding Link State Update 2723 packet, a Link State Acknowledgment packet is sent either to the 2724 multicast address AllSPFRouters, to the multicast address 2725 AllDRouters, or as a unicast (see Section 13.5 of [Ref1] for 2726 details). 2728 The format of this packet is similar to that of the Data Description 2729 packet. The body of both packets is simply a list of LSA headers. 2731 0 1 2 3 2732 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 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 | 3 | 5 | Packet length | 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 | Router ID | 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | Area ID | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 | Checksum | Instance ID | 0 | 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2742 | | 2743 +- -+ 2744 | | 2745 +- An LSA Header -+ 2746 | | 2747 +- -+ 2748 | | 2749 +- -+ 2750 | | 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 | ... | 2754 Each acknowledged LSA is described by its LSA header. The LSA 2755 header is documented in Section A.4.2. It contains all the 2756 information required to uniquely identify both the LSA and the LSA's 2757 current instance. 2759 A.4 LSA formats 2761 This memo defines seven distinct types of LSAs. Each LSA begins 2762 with a standard 20 byte LSA header. This header is explained in 2763 Section A.4.2. Succeeding sections then diagram the separate LSA 2764 types. 2766 Each LSA describes a piece of the OSPF routing domain. Every router 2767 originates a router-LSA. A network-LSA is advertised for each link 2768 by its Designated Router. A router's link-local addresses are 2769 advertised to its neighbors in link-LSAs. IPv6 prefixes are 2770 advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs and 2771 AS-external-LSAs. Location of specific routers can be advertised 2772 across area boundaries in inter-area-router-LSAs. All LSAs are then 2773 flooded throughout the OSPF routing domain. The flooding algorithm 2774 is reliable, ensuring that all routers have the same collection of 2775 LSAs. (See Section 3.5 for more information concerning the flooding 2776 algorithm). This collection of LSAs is called the link-state 2777 database. 2779 From the link state database, each router constructs a shortest path 2780 tree with itself as root. This yields a routing table (see Section 2781 11 of [Ref1]). For the details of the routing table build process, 2782 see Section 3.8. 2784 A.4.1 IPv6 Prefix Representation 2786 IPv6 addresses are bit strings of length 128. IPv6 routing 2787 algorithms, and OSPF for IPv6 in particular, advertise IPv6 address 2788 prefixes. IPv6 address prefixes are bit strings whose length ranges 2789 between 0 and 128 bits (inclusive). 2791 Within OSPF, IPv6 address prefixes are always represented by a 2792 combination of three fields: PrefixLength, PrefixOptions, and 2793 Address Prefix. PrefixLength is the length in bits of the prefix. 2794 PrefixOptions is an 8-bit field describing various capabilities 2795 associated with the prefix (see Section A.4.2). Address Prefix is an 2796 encoding of the prefix itself as an even multiple of 32-bit words, 2797 padding with zero bits as necessary; this encoding consumes 2798 (PrefixLength + 31) / 32) 32-bit words. 2800 The default route is represented by a prefix of length 0. 2802 Examples of IPv6 Prefix representation in OSPF can be found in 2803 Sections A.4.5, A.4.7, A.4.8 and A.4.9. 2805 A.4.1.1 Prefix Options 2807 Each prefix is advertised along with an 8-bit field of capabilities. 2808 These serve as input to the various routing calculations, allowing, 2809 for example, certain prefixes to be ignored in some cases, or to be 2810 marked as not readvertisable in others. 2812 0 1 2 3 4 5 6 7 2813 +--+--+--+--+--+--+--+--+ 2814 | | | | | P|MC|LA|NU| 2815 +--+--+--+--+--+--+--+--+ 2817 The Prefix Options field 2819 NU-bit 2820 The "no unicast" capability bit. If set, the prefix should be 2821 excluded from IPv6 unicast calculations, otherwise it should be 2822 included. 2824 LA-bit 2825 The "local address" capability bit. If set, the prefix is 2826 actually an IPv6 interface address of the advertising router. 2828 MC-bit 2829 The "multicast" capability bit. If set, the prefix should be 2830 included in IPv6 multicast routing calculations, otherwise it 2831 should be excluded. 2833 P-bit 2834 The "propagate" bit. Set on NSSA area prefixes that should be 2835 readvertised at the NSSA area border. 2837 A.4.2 The LSA header 2839 All LSAs begin with a common 20 byte header. This header contains 2840 enough information to uniquely identify the LSA (LS type, Link State 2841 ID, and Advertising Router). Multiple instances of the LSA may 2842 exist in the routing domain at the same time. It is then necessary 2843 to determine which instance is more recent. This is accomplished by 2844 examining the LS age, LS sequence number and LS checksum fields that 2845 are also contained in the LSA header. 2847 0 1 2 3 2848 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 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2850 | LS age | LS type | 2851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 | Link State ID | 2853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 | Advertising Router | 2855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2856 | LS sequence number | 2857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 | LS checksum | length | 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 LS age 2862 The time in seconds since the LSA was originated. 2864 LS type 2865 The LS type field indicates the function performed by the LSA. 2866 The high-order three bits of LS type encode generic properties 2867 of the LSA, while the remainder (called LSA function code) 2868 indicate the LSA's specific functionality. See Section A.4.2.1 2869 for a detailed description of LS type. 2871 Link State ID 2872 Together with LS type and Advertising Router, uniquely 2873 identifies the LSA in the link-state database. 2875 Advertising Router 2876 The Router ID of the router that originated the LSA. For 2877 example, in network-LSAs this field is equal to the Router ID of 2878 the network's Designated Router. 2880 LS sequence number 2881 Detects old or duplicate LSAs. Successive instances of an LSA 2882 are given successive LS sequence numbers. See Section 12.1.6 in 2883 [Ref1] for more details. 2885 LS checksum 2886 The Fletcher checksum of the complete contents of the LSA, 2887 including the LSA header but excluding the LS age field. See 2888 Section 12.1.7 in [Ref1] for more details. 2890 length 2891 The length in bytes of the LSA. This includes the 20 byte LSA 2892 header. 2894 A.4.2.1 LS type 2896 The LS type field indicates the function performed by the LSA. The 2897 high-order three bits of LS type encode generic properties of the 2898 LSA, while the remainder (called LSA function code) indicate the 2899 LSA's specific functionality. The format of the LS type is as 2900 follows: 2902 1 2903 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2904 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2905 |U |S2|S1| LSA Function Code | 2906 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2908 The U bit indicates how the LSA should be handled by a router which 2909 does not recognize the LSA's function code. Its values are: 2911 U-bit LSA Handling 2912 ____________________________________________________________ 2913 0 Treat the LSA as if it had link-local flooding scope 2914 1 Store and flood the LSA, as if type understood 2916 The S1 and S2 bits indicate the flooding scope of the LSA. The 2917 values are: 2919 S2 S1 Flooding Scope 2920 _______________________________________________________________________ 2921 0 0 Link-Local Scoping. Flooded only on link it is originated on. 2922 0 1 Area Scoping. Flooded to all routers in the originating area 2923 1 0 AS Scoping. Flooded to all routers in the AS 2924 1 1 Reserved 2926 The LSA function codes are defined as follows. The origination and 2927 processing of these LSA function codes are defined elsewhere in this 2928 memo, except for the group-membership-LSA (see [Ref7]) and the 2929 Type-7-LSA (see [Ref8]). Each LSA function code also implies a 2930 specific setting for the U, S1 and S2 bits, as shown below. 2932 LSA function code LS Type Description 2933 ___________________________________________________ 2934 1 0x2001 Router-LSA 2935 2 0x2002 Network-LSA 2936 3 0x2003 Inter-Area-Prefix-LSA 2937 4 0x2004 Inter-Area-Router-LSA 2938 5 0x4005 AS-External-LSA 2939 6 0x2006 Group-membership-LSA 2940 7 0x2007 Type-7-LSA 2941 8 0x0008 Link-LSA 2942 9 0x2009 Intra-Area-Prefix-LSA 2943 A.4.3 Router-LSAs 2945 Router-LSAs have LS type equal to 0x2001. Each router in an area 2946 originates one or more router-LSAs. The complete collection of 2947 router-LSAs originated by the router describe the state and cost of 2948 the router's interfaces to the area. For details concerning the 2949 construction of router-LSAs, see Section 3.4.3.1. Router-LSAs are 2950 flooded throughout a single area only. 2952 0 1 2 3 2953 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 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 | LS age |0|0|1| 1 | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 | Link State ID | 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2959 | Advertising Router | 2960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2961 | LS sequence number | 2962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2963 | LS checksum | length | 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | 0 |W|V|E|B| Options | 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2967 | Type | 0 | Metric | 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 | Interface ID | 2970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 | Neighbor Interface ID | 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2973 | Neighbor Router ID | 2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2975 | ... | 2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2977 | Type | 0 | Metric | 2978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2979 | Interface ID | 2980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2981 | Neighbor Interface ID | 2982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2983 | Neighbor Router ID | 2984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2985 | ... | 2987 A single router may originate one or more Router LSAs, distinguished 2988 by their Link-State IDs (which are chosen arbitrarily by the 2989 originating router). The Options field and V, E and B bits should 2990 be the same in all Router LSAs from a single originator. However, 2991 in the case of a mismatch the values in the LSA with the lowest Link 2992 State ID take precedence. When more than one Router LSA is received 2993 from a single router, the links are processed as if concatenated 2994 into a single LSA. 2996 bit V 2997 When set, the router is an endpoint of one or more fully 2998 adjacent virtual links having the described area as Transit area 2999 (V is for virtual link endpoint). 3001 bit E 3002 When set, the router is an AS boundary router (E is for 3003 external). 3005 bit B 3006 When set, the router is an area border router (B is for border). 3008 bit W 3009 When set, the router is a wild-card multicast receiver. When 3010 running MOSPF, these routers receive all multicast datagrams, 3011 regardless of destination. See Sections 3, 4 and A.2 of [Ref8] 3012 for details. 3014 Options 3015 The optional capabilities supported by the router, as documented 3016 in Section A.2. 3018 The following fields are used to describe each router interface. 3019 The Type field indicates the kind of interface being described. It 3020 may be an interface to a transit network, a point-to-point 3021 connection to another router or a virtual link. The values of all 3022 the other fields describing a router interface depend on the 3023 interface's Type field. 3025 Type 3026 The kind of interface being described. One of the following: 3028 Type Description 3029 __________________________________________________ 3030 1 Point-to-point connection to another router 3031 2 Connection to a transit network 3032 3 Reserved 3033 4 Virtual link 3035 Metric 3036 The cost of using this router interface, for outbound traffic. 3038 Interface ID 3039 The Interface ID assigned to the interface being described. See 3040 Sections 3.1.2 and C.3. 3042 Neighbor Interface ID 3043 The Interface ID the neighbor router (or the attached link's 3044 Designated Router, for Type 2 interfaces) has been advertising 3045 in hello packets sent on the attached link. 3047 Neighbor Router ID 3048 The Router ID the neighbor router (or the attached link's 3049 Designated Router, for Type 2 interfaces). 3051 For Type 2 links, the combination of Neighbor Interface ID and 3052 Neighbor Router ID allows the network-LSA for the attached link 3053 to be found in the link-state database. 3055 A.4.4 Network-LSAs 3057 Network-LSAs have LS type equal to 0x2002. A network-LSA is 3058 originated for each broadcast and NBMA link in the area which 3059 supports two or more routers. The network-LSA is originated by the 3060 link's Designated Router. The LSA describes all routers attached to 3061 the link, including the Designated Router itself. The LSA's Link 3062 State ID field is set to the Interface ID that the Designated Router 3063 has been advertising in Hello packets on the link. 3065 The distance from the network to all attached routers is zero. This 3066 is why the metric fields need not be specified in the network-LSA. 3067 For details concerning the construction of network-LSAs, see Section 3068 3.4.3.2. 3070 0 1 2 3 3071 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 3072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3073 | LS age |0|0|1| 2 | 3074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 | Link State ID | 3076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 | Advertising Router | 3078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3079 | LS sequence number | 3080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3081 | LS checksum | length | 3082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3083 | 0 | Options | 3084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3085 | Attached Router | 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3087 | ... | 3089 Attached Router 3090 The Router IDs of each of the routers attached to the link. 3091 Actually, only those routers that are fully adjacent to the 3092 Designated Router are listed. The Designated Router includes 3093 itself in this list. The number of routers included can be 3094 deduced from the LSA header's length field. 3096 A.4.5 Inter-Area-Prefix-LSAs 3098 Inter-Area-Prefix-LSAs have LS type equal to 0x2003. These LSAs are 3099 are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see 3100 Section 12.4.3 of [Ref1]). Originated by area border routers, they 3101 describe routes to IPv6 address prefixes that belong to other areas. 3102 A separate Inter-Area-Prefix-LSA is originated for each IPv6 address 3103 prefix. For details concerning the construction of Inter-Area- 3104 Prefix-LSAs, see Section 3.4.3.3. 3106 For stub areas, Inter-Area-Prefix-LSAs can also be used to describe 3107 a (per-area) default route. Default summary routes are used in stub 3108 areas instead of flooding a complete set of external routes. When 3109 describing a default summary route, the Inter-Area-Prefix-LSA's 3110 PrefixLength is set to 0. 3112 0 1 2 3 3113 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 3114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3115 | LS age |0|0|1| 3 | 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3117 | Link State ID | 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 | Advertising Router | 3120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3121 | LS sequence number | 3122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3123 | LS checksum | length | 3124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3125 | 0 | Metric | 3126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3127 | PrefixLength | PrefixOptions | (0) | 3128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3129 | Address Prefix | 3130 | ... | 3131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3133 Metric 3134 The cost of this route. Expressed in the same units as the 3135 interface costs in the router-LSAs. When the Inter-Area-Prefix- 3136 LSA is describing a route to a range of addresses (see Section 3137 C.2) the cost is set to the maximum cost to any reachable 3138 component of the address range. 3140 PrefixLength, PrefixOptions and Address Prefix 3141 Representation of the IPv6 address prefix, as described in 3142 Section A.4.1. 3144 A.4.6 Inter-Area-Router-LSAs 3146 Inter-Area-Router-LSAs have LS type equal to 0x2004. These LSAs are 3147 are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see 3148 Section 12.4.3 of [Ref1]). Originated by area border routers, they 3149 describe routes to routers in other areas. (To see why it is 3150 necessary to advertise the location of each ASBR, consult Section 3151 16.4 in [Ref1].) Each LSA describes a route to a single router. For 3152 details concerning the construction of Inter-Area-Router-LSAs, see 3153 Section 3.4.3.4. 3155 0 1 2 3 3156 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 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | LS age |0|0|1| 4 | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 | Link State ID | 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3162 | Advertising Router | 3163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3164 | LS sequence number | 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 | LS checksum | length | 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3168 | 0 | Options | 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 | 0 | Metric | 3171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3172 | Destination Router ID | 3173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 Options 3176 The optional capabilities supported by the router, as documented 3177 in Section A.2. 3179 Metric 3180 The cost of this route. Expressed in the same units as the 3181 interface costs in the router-LSAs. 3183 Destination Router ID 3184 The Router ID of the router being described by the LSA. 3186 A.4.7 AS-external-LSAs 3188 AS-external-LSAs have LS type equal to 0x4005. These LSAs are 3189 originated by AS boundary routers, and describe destinations 3190 external to the AS. Each LSA describes a route to a single IPv6 3191 address prefix. For details concerning the construction of AS- 3192 external-LSAs, see Section 3.4.3.5. 3194 AS-external-LSAs can be used to describe a default route. Default 3195 routes are used when no specific route exists to the destination. 3196 When describing a default route, the AS-external-LSA's PrefixLength 3197 is set to 0. 3199 0 1 2 3 3200 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 3201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3202 | LS age |0|1|0| 5 | 3203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3204 | Link State ID | 3205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3206 | Advertising Router | 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 | LS sequence number | 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | LS checksum | length | 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3212 | |E|F|T| Metric | 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 | PrefixLength | PrefixOptions | Referenced LS Type | 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3216 | Address Prefix | 3217 | ... | 3218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 | | 3220 +- -+ 3221 | | 3222 +- Forwarding Address (Optional) -+ 3223 | | 3224 +- -+ 3225 | | 3226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 | External Route Tag (Optional) | 3228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3229 | Referenced Link State ID (Optional) | 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3232 bit E 3233 The type of external metric. If bit E is set, the metric 3234 specified is a Type 2 external metric. This means the metric is 3235 considered larger than any intra-AS path. If bit E is zero, the 3236 specified metric is a Type 1 external metric. This means that 3237 it is expressed in the same units as the link state metric 3238 (i.e., the same units as interface cost). 3240 bit F 3241 If set, a Forwarding Address has been included in the LSA. 3243 bit T 3244 If set, an External Route Tag has been included in the LSA. 3246 Metric 3247 The cost of this route. Interpretation depends on the external 3248 type indication (bit E above). 3250 PrefixLength, PrefixOptions and Address Prefix 3251 Representation of the IPv6 address prefix, as described in 3252 Section A.4.1. 3254 Referenced LS type 3255 If non-zero, an LSA with this LS type is to be associated with 3256 this LSA (see Referenced Link State ID below). 3258 Forwarding address 3259 A fully qualified IPv6 address (128 bits). Included in the LSA 3260 if and only if bit F has been set. If included, Data traffic 3261 for the advertised destination will be forwarded to this 3262 address. Must not be set to the IPv6 Unspecified Address 3263 (0:0:0:0:0:0:0:0). 3265 External Route Tag 3266 A 32-bit field which may be used to communicate additional 3267 information between AS boundary routers; see [Ref5] for example 3268 usage. Included in the LSA if and only if bit T has been set. 3270 Referenced Link State ID 3271 Included if and only if Reference LS Type is non-zero. If 3272 included, additional information concerning the advertised 3273 external route can be found in the LSA having LS type equal to 3274 "Referenced LS Type", Link State ID equal to "Referenced Link 3275 State ID" and Advertising Router the same as that specified in 3276 the AS-external-LSA's link state header. This additional 3277 information is not used by the OSPF protocol itself. It may be 3278 used to communicate information between AS boundary routers; the 3279 precise nature of such information is outside the scope of this 3280 specification. 3282 All, none or some of the fields labeled Forwarding address, External 3283 Route Tag and Referenced Link State ID may be present in the AS- 3284 external-LSA (as indicated by the setting of bit F, bit T and 3285 Referenced LS type respectively). However, when present Forwarding 3286 Address always comes first, with External Route Tag always preceding 3287 Referenced Link State ID. 3289 A.4.8 Link-LSAs 3291 Link-LSAs have LS type equal to 0x0008. A router originates a 3292 separate Link-LSA for each link it is attached to. These LSAs have 3293 local-link flooding scope; they are never flooded beyond the link 3294 that they are associated with. Link-LSAs have three purposes: 1) 3295 they provide the router's link-local address to all other routers 3296 attached to the link and 2) they inform other routers attached to 3297 the link of a list of IPv6 prefixes to associate with the link and 3298 3) they allow the router to assert a collection of Options bits to 3299 associate with the Network-LSA that will be originated for the link. 3301 A link-LSA's Link State ID is set equal to the originating router's 3302 Interface ID on the link. 3303 0 1 2 3 3304 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 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 | LS age |0|0|0| 8 | 3307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3308 | Link State ID | 3309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3310 | Advertising Router | 3311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3312 | LS sequence number | 3313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3314 | LS checksum | length | 3315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3316 | Rtr Pri | Options | 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 | | 3319 +- -+ 3320 | | 3321 +- Link-local Interface Address -+ 3322 | | 3323 +- -+ 3324 | | 3325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3326 | # prefixes | 3327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3328 | PrefixLength | PrefixOptions | (0) | 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3330 | Address Prefix | 3331 | ... | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | ... | 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 | PrefixLength | PrefixOptions | (0) | 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 | Address Prefix | 3338 | ... | 3339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 Rtr Pri 3342 The Router Priority of the interface attaching the originating 3343 router to the link. 3345 Options 3346 The set of Options bits that the router would like set in the 3347 Network-LSA that will be originated for the link. 3349 Link-local Interface Address 3350 The originating router's link-local interface address on the 3351 link. 3353 # prefixes 3354 The number of IPv6 address prefixes contained in the LSA. 3356 The rest of the link-LSA contains a list of IPv6 prefixes to be 3357 associated with the link. 3359 PrefixLength, PrefixOptions and Address Prefix 3360 Representation of an IPv6 address prefix, as described in 3361 Section A.4.1. 3363 A.4.9 Intra-Area-Prefix-LSAs 3365 Intra-Area-Prefix-LSAs have LS type equal to 0x2009. A router uses 3366 Intra-Area-Prefix-LSAs to advertise one or more IPv6 address 3367 prefixes that are associated with a) the router itself, b) an 3368 attached stub network segment or c) an attached transit network 3369 segment. In IPv4, a) and b) were accomplished via the router's 3370 router-LSA, and c) via a network-LSA. However, in OSPF for IPv6 all 3371 addressing information has been removed from router-LSAs and 3372 network-LSAs, leading to the introduction of the Intra-Area-Prefix- 3373 LSA. 3375 A router can originate multiple Intra-Area-Prefix-LSAs for each 3376 router or transit network; each such LSA is distinguished by its 3377 Link State ID. 3379 0 1 2 3 3380 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 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3382 | LS age |0|0|1| 9 | 3383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3384 | Link State ID | 3385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3386 | Advertising Router | 3387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3388 | LS sequence number | 3389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3390 | LS checksum | length | 3391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3392 | # prefixes | Referenced LS type | 3393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3394 | Referenced Link State ID | 3395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3396 | Referenced Advertising Router | 3397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3398 | PrefixLength | PrefixOptions | Metric | 3399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3400 | Address Prefix | 3401 | ... | 3402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 | ... | 3404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3405 | PrefixLength | PrefixOptions | Metric | 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 | Address Prefix | 3408 | ... | 3409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3411 # prefixes 3412 The number of IPv6 address prefixes contained in the LSA. 3414 Referenced LS type, Referenced Link State ID and Referenced 3415 Advertising Router 3416 Identifies the router-LSA or network-LSA with which the IPv6 3417 address prefixes should be associated. If Referenced LS type is 3418 1, the prefixes are associated with a router-LSA, Referenced 3419 Link State ID should be 0 and Referenced Advertising Router 3420 should be the originating router's Router ID. If Referenced LS 3421 type is 2, the prefixes are associated with a network-LSA, 3422 Referenced Link State ID should be the Interface ID of the 3423 link's Designated Router and Referenced Advertising Router 3424 should be the Designated Router's Router ID. 3426 The rest of the Intra-Area-Prefix-LSA contains a list of IPv6 3427 prefixes to be associated with the router or transit link, together 3428 with the cost of each prefix. 3430 PrefixLength, PrefixOptions and Address Prefix 3431 Representation of an IPv6 address prefix, as described in 3432 Section A.4.1. 3434 Metric 3435 The cost of this prefix. Expressed in the same units as the 3436 interface costs in the router-LSAs. 3438 B. Architectural Constants 3440 Architectural constants for the OSPF protocol are defined in 3441 Appendix C of [Ref1]. The only difference for OSPF for IPv6 is that 3442 DefaultDestination is encoded as a prefix of length 0 (see Section 3443 A.4.1). 3445 C. Configurable Constants 3447 The OSPF protocol has quite a few configurable parameters. These 3448 parameters are listed below. They are grouped into general 3449 functional categories (area parameters, interface parameters, etc.). 3450 Sample values are given for some of the parameters. 3452 Some parameter settings need to be consistent among groups of 3453 routers. For example, all routers in an area must agree on that 3454 area's parameters, and all routers attached to a network must agree 3455 on that network's HelloInterval and RouterDeadInterval. 3457 Some parameters may be determined by router algorithms outside of 3458 this specification (e.g., the address of a host connected to the 3459 router via a SLIP line). From OSPF's point of view, these items are 3460 still configurable. 3462 C.1 Global parameters 3464 In general, a separate copy of the OSPF protocol is run for each 3465 area. Because of this, most configuration parameters are 3466 defined on a per-area basis. The few global configuration 3467 parameters are listed below. 3469 Router ID 3470 This is a 32-bit number that uniquely identifies the router 3471 in the Autonomous System. If a router's OSPF Router ID is 3472 changed, the router's OSPF software should be restarted 3473 before the new Router ID takes effect. Before restarting in 3474 order to change its Router ID, the router should flush its 3475 self-originated LSAs from the routing domain (see Section 3476 14.1 of [Ref1]), or they will persist for up to MaxAge 3477 minutes. 3479 Because the size of the Router ID is smaller than an IPv6 3480 address, it cannot be set to one of the router's IPv6 3481 addresses (as is commonly done for IPv4). Possible Router ID 3482 assignment procedures for IPv6 include: a) assign the IPv6 3483 Router ID as one of the router's IPv4 addresses or b) assign 3484 IPv6 Router IDs through some local administrative procedure 3485 (similar to procedures used by manufacturers to assign 3486 product serial numbers). 3488 The Router ID of 0.0.0.0 is reserved, and should not be 3489 used. 3491 C.2 Area parameters 3493 All routers belonging to an area must agree on that area's 3494 configuration. Disagreements between two routers will lead to 3495 an inability for adjacencies to form between them, with a 3496 resulting hindrance to the flow of routing protocol and data 3497 traffic. The following items must be configured for an area: 3499 Area ID 3500 This is a 32-bit number that identifies the area. The Area 3501 ID of 0 is reserved for the backbone. 3503 List of address ranges 3504 Address ranges control the advertisement of routes across 3505 area boundaries. Each address range consists of the 3506 following items: 3508 [IPv6 prefix, prefix length] 3509 Describes the collection of IPv6 addresses contained 3510 in the address range. 3512 Status Set to either Advertise or DoNotAdvertise. Routing 3513 information is condensed at area boundaries. 3514 External to the area, at most a single route is 3515 advertised (via a inter-area-prefix-LSA) for each 3516 address range. The route is advertised if and only 3517 if the address range's Status is set to Advertise. 3518 Unadvertised ranges allow the existence of certain 3519 networks to be intentionally hidden from other 3520 areas. Status is set to Advertise by default. 3522 ExternalRoutingCapability 3523 Whether AS-external-LSAs will be flooded into/throughout the 3524 area. If AS-external-LSAs are excluded from the area, the 3525 area is called a "stub". Internal to stub areas, routing to 3526 external destinations will be based solely on a default 3527 inter-area route. The backbone cannot be configured as a 3528 stub area. Also, virtual links cannot be configured through 3529 stub areas. For more information, see Section 3.6 of 3530 [Ref1]. 3532 StubDefaultCost 3533 If the area has been configured as a stub area, and the 3534 router itself is an area border router, then the 3535 StubDefaultCost indicates the cost of the default inter- 3536 area-prefix-LSA that the router should advertise into the 3537 area. See Section 12.4.3.1 of [Ref1] for more information. 3539 C.3 Router interface parameters 3541 Some of the configurable router interface parameters (such as 3542 Area ID, HelloInterval and RouterDeadInterval) actually imply 3543 properties of the attached links, and therefore must be 3544 consistent across all the routers attached to that link. The 3545 parameters that must be configured for a router interface are: 3547 IPv6 link-local address 3548 The IPv6 link-local address associated with this interface. 3549 May be learned through auto-configuration. 3551 Area ID 3552 The OSPF area to which the attached link belongs. 3554 Instance ID 3555 The OSPF protocol instance associated with this OSPF 3556 interface. Defaults to 0. 3558 Interface ID 3559 32-bit number uniquely identifying this interface among the 3560 collection of this router's interfaces. For example, in some 3561 implementations it may be possible to use the MIB-II 3562 IfIndex. 3564 IPv6 prefixes 3565 The list of IPv6 prefixes to associate with the link. These 3566 will be advertised in intra-area-prefix-LSAs. 3568 Interface output cost(s) 3569 The cost of sending a packet on the interface, expressed in 3570 the link state metric. This is advertised as the link cost 3571 for this interface in the router's router-LSA. The interface 3572 output cost must always be greater than 0. 3574 RxmtInterval 3575 The number of seconds between LSA retransmissions, for 3576 adjacencies belonging to this interface. Also used when 3577 retransmitting Database Description and Link State Request 3578 Packets. This should be well over the expected round-trip 3579 delay between any two routers on the attached link. The 3580 setting of this value should be conservative or needless 3581 retransmissions will result. Sample value for a local area 3582 network: 5 seconds. 3584 InfTransDelay 3585 The estimated number of seconds it takes to transmit a Link 3586 State Update Packet over this interface. LSAs contained in 3587 the update packet must have their age incremented by this 3588 amount before transmission. This value should take into 3589 account the transmission and propagation delays of the 3590 interface. It must be greater than 0. Sample value for a 3591 local area network: 1 second. 3593 Router Priority 3594 An 8-bit unsigned integer. When two routers attached to a 3595 network both attempt to become Designated Router, the one 3596 with the highest Router Priority takes precedence. If there 3597 is still a tie, the router with the highest Router ID takes 3598 precedence. A router whose Router Priority is set to 0 is 3599 ineligible to become Designated Router on the attached link. 3600 Router Priority is only configured for interfaces to 3601 broadcast and NBMA networks. 3603 HelloInterval 3604 The length of time, in seconds, between the Hello Packets 3605 that the router sends on the interface. This value is 3606 advertised in the router's Hello Packets. It must be the 3607 same for all routers attached to a common link. The smaller 3608 the HelloInterval, the faster topological changes will be 3609 detected; however, more OSPF routing protocol traffic will 3610 ensue. Sample value for a X.25 PDN: 30 seconds. Sample 3611 value for a local area network (LAN): 10 seconds. 3613 RouterDeadInterval 3614 After ceasing to hear a router's Hello Packets, the number 3615 of seconds before its neighbors declare the router down. 3616 This is also advertised in the router's Hello Packets in 3617 their RouterDeadInterval field. This should be some 3618 multiple of the HelloInterval (say 4). This value again 3619 must be the same for all routers attached to a common link. 3621 C.4 Virtual link parameters 3623 Virtual links are used to restore/increase connectivity of the 3624 backbone. Virtual links may be configured between any pair of 3625 area border routers having interfaces to a common (non-backbone) 3626 area. The virtual link appears as an unnumbered point-to-point 3627 link in the graph for the backbone. The virtual link must be 3628 configured in both of the area border routers. 3630 A virtual link appears in router-LSAs (for the backbone) as if 3631 it were a separate router interface to the backbone. As such, 3632 it has most of the parameters associated with a router interface 3633 (see Section C.3). Virtual links do not have link-local 3634 addresses, but instead use one of the router's global-scope or 3635 site-local IPv6 addresses as the IP source in OSPF protocol 3636 packets it sends along the virtual link. Router Priority is not 3637 used on virtual links. Interface output cost is not configured 3638 on virtual links, but is dynamically set to be the cost of the 3639 intra-area path between the two endpoint routers. The parameter 3640 RxmtInterval must be configured, and should be well over the 3641 expected round-trip delay between the two routers. This may be 3642 hard to estimate for a virtual link; it is better to err on the 3643 side of making it too large. 3645 A virtual link is defined by the following two configurable 3646 parameters: the Router ID of the virtual link's other endpoint, 3647 and the (non-backbone) area through which the virtual link runs 3648 (referred to as the virtual link's Transit area). Virtual links 3649 cannot be configured through stub areas. 3651 C.5 NBMA network parameters 3653 OSPF treats an NBMA network much like it treats a broadcast 3654 network. Since there may be many routers attached to the 3655 network, a Designated Router is selected for the network. This 3656 Designated Router then originates a network-LSA, which lists all 3657 routers attached to the NBMA network. 3659 However, due to the lack of broadcast capabilities, it may be 3660 necessary to use configuration parameters in the Designated 3661 Router selection. These parameters will only need to be 3662 configured in those routers that are themselves eligible to 3663 become Designated Router (i.e., those router's whose Router 3664 Priority for the network is non-zero), and then only if no 3665 automatic procedure for discovering neighbors exists: 3667 List of all other attached routers 3668 The list of all other routers attached to the NBMA network. 3669 Each router is configured with its Router ID and IPv6 link- 3670 local address on the network. Also, for each router listed, 3671 that router's eligibility to become Designated Router must 3672 be defined. When an interface to a NBMA network comes up, 3673 the router sends Hello Packets only to those neighbors 3674 eligible to become Designated Router, until the identity of 3675 the Designated Router is discovered. 3677 PollInterval 3678 If a neighboring router has become inactive (Hello Packets 3679 have not been seen for RouterDeadInterval seconds), it may 3680 still be necessary to send Hello Packets to the dead 3681 neighbor. These Hello Packets will be sent at the reduced 3682 rate PollInterval, which should be much larger than 3683 HelloInterval. Sample value for a PDN X.25 network: 2 3684 minutes. 3686 C.6 Point-to-MultiPoint network parameters 3688 On Point-to-MultiPoint networks, it may be necessary to 3689 configure the set of neighbors that are directly reachable over 3690 the Point-to-MultiPoint network. Each neighbor is configured 3691 with its Router ID and IPv6 link-local address on the network. 3692 Designated Routers are not elected on Point-to-MultiPoint 3693 networks, so the Designated Router eligibility of configured 3694 neighbors is undefined. 3696 C.7 Host route parameters 3698 Host routes are advertised in intra-area-prefix-LSAs as fully 3699 qualified IPv6 prefixes (i.e., prefix length set equal to 128 3700 bits). They indicate either router interfaces to point-to-point 3701 networks, looped router interfaces, or IPv6 hosts that are 3702 directly connected to the router (e.g., via a PPP connection). 3703 For each host directly connected to the router, the following 3704 items must be configured: 3706 Host IPv6 address 3707 The IPv6 address of the host. 3709 Cost of link to host 3710 The cost of sending a packet to the host, in terms of the 3711 link state metric. However, since the host probably has only 3712 a single connection to the internet, the actual configured 3713 cost(s) in many cases is unimportant (i.e., will have no 3714 effect on routing). 3716 Area ID 3717 The OSPF area to which the host belongs. 3719 Security Considerations 3721 When running over IPv6, OSPF relies on the IP Authentication Header 3722 (see [Ref19]) and the IP Encapsulating Security Payload (see 3723 [Ref20]) to ensure integrity and authentication/confidentiality of 3724 routing exchanges. 3726 Authors Addresses 3728 Rob Coltun 3729 FORE Systems 3730 Phone: (301) 571-2521 3731 Email: rcoltun@fore.com 3733 Dennis Ferguson 3734 Juniper Networks 3735 101 University Avenue, Suite 240 3736 Palo Alto, CA 94301 3737 Phone: (415) 614-4143 3738 Email: dennis@jnx.com 3740 John Moy 3741 Ascend Communications Inc. 3742 1 Robbins Road 3743 Westford, MA 01886 3744 Phone: (978) 952-1367 3745 Fax: (978) 392-2075 3746 Email: jmoy@casc.com 3748 This document expires in May 1998.