idnits 2.17.1 draft-ietf-ospf-ospfv6-04.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-23) 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 2692 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 (March 1997) is 9901 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 2162, but no explicit reference was found in the text == Unused Reference: 'Ref3' is defined on line 2165, but no explicit reference was found in the text == Unused Reference: 'Ref4' is defined on line 2170, but no explicit reference was found in the text == Unused Reference: 'Ref6' is defined on line 2178, but no explicit reference was found in the text == Unused Reference: 'Ref12' is defined on line 2586, but no explicit reference was found in the text == Unused Reference: 'Ref13' is defined on line 2200, but no explicit reference was found in the text == Unused Reference: 'Ref16' is defined on line 2212, but no explicit reference was found in the text == Unused Reference: 'Ref17' is defined on line 2217, but no explicit reference was found in the text == Unused Reference: 'Ref18' is defined on line 2220, 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: September 1997 D. Ferguson 5 File name: draft-ietf-ospf-ospfv6-04.txt Juniper Networks 6 Network Working Group J. Moy 7 Internet Draft Cascade Communications Corp. 8 March 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 2.12 Removal of TOS ........................................ 12 76 3 Implementation details ................................ 12 77 3.1 Protocol data structures .............................. 14 78 3.1.1 The Area Data structure ............................... 14 79 3.1.2 The Interface Data structure .......................... 14 80 3.1.3 The Neighbor Data Structure ........................... 16 81 3.2 Protocol Packet Processing ............................ 17 82 3.2.1 Sending protocol packets .............................. 17 83 3.2.1.1 Sending Hello packets ................................. 18 84 3.2.1.2 Sending Database Description Packets .................. 19 85 3.2.2 Receiving protocol packets ............................ 19 86 3.2.2.1 Receiving Hello Packets ............................... 21 87 3.3 The Routing table Structure ........................... 22 88 3.3.1 Routing table lookup .................................. 23 89 3.4 Link State Advertisements ............................. 23 90 3.4.1 The LSA Header ........................................ 23 91 3.4.2 The link-state database ............................... 24 92 3.4.3 Originating LSAs ...................................... 25 93 3.4.3.1 Router-LSAs ........................................... 27 94 3.4.3.2 Network-LSAs .......................................... 29 95 3.4.3.3 Inter-Area-Prefix-LSAs ................................ 30 96 3.4.3.4 Inter-Area-Router-LSAs ................................ 31 97 3.4.3.5 AS-external-LSAs ...................................... 32 98 3.4.3.6 Link-LSAs ............................................. 34 99 3.4.3.7 Intra-Area-Prefix-LSAs ................................ 35 100 3.5 Flooding .............................................. 38 101 3.5.1 Receiving Link State Update packets ................... 39 102 3.5.2 Sending Link State Update packets ..................... 39 103 3.5.3 Installing LSAs in the database ....................... 41 104 3.6 Definition of self-originated LSAs .................... 42 105 3.7 Virtual links ......................................... 42 106 3.8 Routing table calculation ............................. 43 107 3.8.1 Calculating the shortest path tree for an area ........ 44 108 3.8.1.1 The next hop calculation .............................. 45 109 3.8.2 Calculating the inter-area routes ..................... 46 110 3.8.3 Examining transit areas' summary-LSAs ................. 46 111 3.8.4 Calculating AS external routes ........................ 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 a 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 a Interface ID which the originating router has 331 assigned to uniquely identify (among its own interfaces) its 332 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 it's 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 in particular (Section 10.5 500 of [Ref1]). 502 The Router ID of 0.0.0.0 is reserved, and should not be used. 504 2.12. Removal of TOS 506 The semantics of IPv4 TOS have not been moved forward to IPv6. 507 Therefore, support for TOS in OSPF for IPv6 has been removed. 508 This affects both LSA formats and routing calculations. 510 The IPv6 header does have a 24-bit Flow Label field which may be 511 used by a source to label those packets for which it requests 512 special handling by IPv6 routers, such as non-default quality of 513 service or "real-time" service. The OSPF LSAs for IPv6 have been 514 organized so that future extensions to support routing based on 515 Flow Label are possible. 517 3. Implementation details 519 When going from IPv4 to IPv6, the basic OSPF mechanisms remain 520 unchanged from those documented in [Ref1]. These mechanisms are 521 briefly outlined in Section 4 of [Ref1]. Both IPv6 and IPv4 have a 522 link-state database composed of LSAs and synchronized between 523 adjacent routers. Initial synchronization is performed through the 524 Database Exchange process, through the exchange of Database 525 Description, Link State Request and Link State Update packets. 526 Thereafter database synchronization is maintained via flooding, 527 utilizing Link State Update and Link State Acknowledgment packets. 528 Both IPv6 and IPv4 use OSPF Hello Packets to disover and maintain 529 neighbor relationships, and to elect Designated Routers and Backup 530 Designated Routers on broadcast and NBMA links. The decision as to 531 which neighbor relationships become adjacencies, along with the 532 basic ideas behind inter-area routing, importing external 533 information in AS-external-LSAs and the various routing calculations 534 are also the same. 536 In particular, the following IPv4 OSPF functionality described in 537 [Ref1] remains completely unchanged for IPv6: 539 o Both IPv4 and IPv6 use OSPF packet types described in Section 540 4.3 of [Ref1], namely: Hello, Database Description, Link State 541 Request, Link State Update and Link State Acknowledgment 542 packets. While in some cases (e.g., Hello packets) their format 543 has changed somewhat, the functions of the various packet types 544 remains the same. 546 o The system requirements for an OSPF implementation remain 547 unchanged, although OSPF for IPv6 requires an IPv6 protocol 548 stack (from the network layer on down) since it runs directly 549 over the IPv6 network layer. 551 o The discovery and maintenance of neighbor relationships, and the 552 selection and establishment of adjacencies remain the same. This 553 includes election of the Designated Router and Backup Designated 554 Router on broadcast and NBMA links. These mechanisms are 555 described in Sections 7, 7.1, 7.2, 7.3, 7.4 and 7.5 of [Ref1]. 557 o The link types (or equivalently, interface types) supported by 558 OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, 559 Point-to-MultiPoint and virtual links. 561 o The interface state machine, including the list of OSPF 562 interface states and events, and the Designated Router and 563 Backup Designated Router election algorithm, remain unchanged. 564 These are described in Sections 9.1, 9.2, 9.3 and 9.4 of [Ref1]. 566 o The neighbor state machine, including the list of OSPF neighbor 567 states and events, remain unchanged. These are described in 568 Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1]. 570 o Aging of the link-state database, as well as flushing LSAs from 571 the routing domain through the premature aging process, remains 572 unchanged from the description in Sections 14 and 14.1 of 573 [Ref1]. 575 However, some OSPF protocol mechanisms have changed, as outlined in 576 Section 2 above. These changes are explained in detail in the 577 following subsections, making references to the appropriate sections 578 of [Ref1]. 580 The following subsections provide a recipe for turning an IPv4 OSPF 581 implementation into an IPv6 OSPF implementation. 583 3.1. Protocol data structures 585 The major OSPF data structures are the same for both IPv4 and 586 IPv6: areas, interfaces, neighbors, the link-state database and 587 the routing table. The top-level data structures for IPv6 remain 588 those listed in Section 5 of [Ref1], with the following 589 modifications: 591 o All LSAs with known LS type and AS flooding scope appear in 592 the top-level data structure, instead of belonging to a 593 specific area or link. AS-external-LSAs are the only LSAs 594 defined by this specification which have AS flooding scope. 595 LSAs with unknown LS type, U-bit set to 1 (flood even when 596 unrecognized) and AS flooding scope also appear in the top- 597 level data structure. 599 o Since IPv6 does not have the concept of TOS, "TOS 600 capability" is not a part of the OSPF fro IPv6 601 specification. 603 3.1.1. The Area Data structure 605 The IPv6 area data structure contains all elements defined 606 for IPv4 areas in Section 6 of [Ref1]. In addition, all LSAs 607 of known type which have area flooding scope are contained 608 in the IPv6 area data structure. This always includes the 609 following LSA types: router-LSAs, network-LSAs, inter-area- 610 prefix-LSAs, inter-area-router-LSAs and intra-area-prefix- 611 LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even 612 when unrecognized) and area scope also appear in the area 613 data structure. IPv6 routers implementing MOSPF add group- 614 membership-LSAs to the area data structure. Type-7-LSAs 615 belong to an NSSA area's data structure. 617 3.1.2. The Interface Data structure 619 In OSPF for IPv6, an interface connects a router to a link. 620 The IPv6 interface structure modifies the IPv4 interface 621 structure (as defined in Section 9 of [Ref1]) as follows: 623 Interface ID 624 Every interface is assigned an Interface ID, which 625 uniquely identifies the interface with the router. For 626 example, some implementations may be able to use the 627 MIB-II IfIndex as Interface ID. The Interface ID appears 628 in Hello packets sent out the interface, the link- 629 local-LSA originated by router for the attached link, 630 and the router-LSA originated by the router-LSA for the 631 associated area. It will also serve as the Link State ID 632 for the network-LSA that the router will originate for 633 the link if the router is elected Designated Router. 635 Instance ID 636 Every interface is assigned an Instance ID. This should 637 default to 0, and is only necessary to assign 638 differently on those links that will contain multiple 639 separate communities of OSPF Routers. For example, 640 suppose that there are two communities of routers on a 641 given ethernet segment that you wish to keep separate. 642 The first community is given an Instance ID of 0, by 643 assigning 0 as the Instance ID of all its routers' 644 interfaces to the ethernet. An Instance ID of 1 is 645 assigned to the other routers' interface to the 646 ethernet. The OSPF transmit and receive processing (see 647 Section 3.2) will then keep the two communities 648 separate. 650 List of LSAs with link-local scope 651 All LSAs with link-local scope and which were 652 originated/flooded on the link belong to the interface 653 structure which connects to the link. This includes the 654 collection of the link's link-LSAs. 656 List of LSAs with unknown LS type 657 All LSAs with unknown LS type and U-bit set to 0 (if 658 unrecognized, treat the LSA as if it had link-local 659 flooding scope) are kept in data structure for the 660 interface that received the LSA. 662 IP interface address 663 For IPv6, the IPv6 address appearing in the source of 664 OSPF packets sent out the interface is almost always a 665 link-local address. The one exception is for virtual 666 links, which must use one of the router's own site-local 667 or global IPv6 addresses as IP interface address. 669 List of link prefixes 670 A list of IPv6 prefixes can be configured for the 671 attached link. These will be advertised by the router in 672 link-LSAs, so that they can be advertised by the link's 673 Designated Router in intra-area-prefix-LSAs. 675 There is only a single interface output cost, as IPv6 has no 676 concept of TOS. In addition, OSPF for IPv6 relies on the IP 677 Authentication Header (see [Ref19]) and the IP Encapsulating 678 Security Payload (see [Ref20]) to ensure integrity and 679 authentication/confidentiality of routing exchanges. For 680 that reason, AuType and Authentication key are not 681 associated with IPv6 OSPF interfaces. 683 Interface states, events, and the interface state machine 684 remain unchanged from IPv4, and are documented in Sections 685 9.1, 9.2 and 9.3 of [Ref1] respectively. The Designated 686 Router and Backup Designated Router election algorithm also 687 remains unchanged from the IPv4 election in Section 9.4 of 688 [Ref1]. 690 3.1.3. The Neighbor Data Structure 692 The neighbor structure performs the same function in both 693 IPv6 and IPv4. Namely, it collects all information required 694 to form an adjacency between two routers, if an adjacency 695 becomes necessary. Each neighbor structure is bound to a 696 single OSPF interface. The differences between the IPv6 697 neighbor structure and the neighbor structure defined for 698 IPv4 in Section 10 of [Ref1] are: 700 Neighbor's Interface ID 701 The Interface ID that the neighbor advertises in its 702 Hello Packets must be recorded in the neighbor 703 structure. The router will include the neighbor's 704 Interface ID in the router's router-LSA when either a) 705 advertising a point-to-point link to the neighbor or b) 706 advertising a link to a network where the neighbor has 707 become Designated Router. 709 Neighbor IP address 710 Except on virtual links, the neighbor's IP address will 711 be an IPv6 link-local address. 713 Neighbor's Designated Router 714 The neighbor's choice of Designated Router is now 715 encoded as Router ID, instead of as an IP address. 717 Neighbor's Backup Designated Router 718 The neighbor's choice of Designated Router is now 719 encoded as Router ID, instead of as an IP address. 721 Neighbor states, events, and the neighbor state machine 722 remain unchanged from IPv4, and are documented in Sections 723 10.1, 10.2 and 10.3 of [Ref1] respectively. The decision as 724 to which adjacencies to form also remains unchanged from the 725 IPv4 logic documented in Section 10.4 of [Ref1]. 727 3.2. Protocol Packet Processing 729 OSPF for IPv6 runs directly over IPv6's network layer. As such, 730 it is encapsulated in one or more IPv6 headers, with the Next 731 Header field of the immediately encapsulating IPv6 header set to 732 the value 89. OSPF protocol packets should be given precedence 733 over regular IPv6 data traffic, in both sending and receiving. 734 as an aid towards accomplishing this precedence, OSPF routing 735 protocol packets are sent with IPv6 Priority field set to 7 736 (internet control traffic). 738 As for IPv4, in IPv6 OSPF routing protocol packets are sent 739 along adjacencies only (with the exception of Hello packets, 740 which are used to discover the adjacencies). OSPF packet types 741 and functions are the same in both IPv4 and IPv4, encoded by the 742 Type field of the standard OSPF packet header. 744 3.2.1. Sending protocol packets 746 When an IPv6 router sends an OSPF routing protocol packet, 747 it fills in the fields of the standard OSPF for IPv6 packet 748 header (see Section A.3.1) as follows: 750 Version # 751 Set to 3, the version number of the protocol as 752 documented in this specification. 754 Type 755 The type of OSPF packet, such as Link state Update or 756 Hello Packet. 758 Packet length 759 The length of the entire OSPF packet in bytes, including 760 the standard OSPF packet header. 762 Router ID 763 The identity of the router itself (who is originating 764 the packet). 766 Area ID 767 The OSPF area that the packet is being sent into. 769 Instance ID 770 The OSPF Instance ID associated with the interface that 771 the packet is being sent out of. 773 Checksum 774 The standard IPv6 16-bit one's complement checksum, 775 covering the entire OSPF packet and prepended IPv6 776 pseudo-header (see Section A.3.1). 778 Selection of OSPF routing protocol packets' IPv6 source and 779 destination addresses is performed identically to the IPv4 780 logic in Section 8.1 of [Ref1]. The IPv6 destination address 781 is chosen from among the addresses AllSPFRouters, 782 AllDRouters and the Neighbor IP address associated with the 783 other end of the adjacency (which in IPv6, for all links 784 except virtual links, is an IPv6 link-local address). 786 The sending of Link State Request Packets and Link State 787 Acknowledgment Packets remains unchanged from the IPv4 788 procedures documented in Sections 10.9 and 13.5 of [Ref1] 789 respectively. Sending Hello Packets is documented in Section 790 3.2.1.1, and the sending of Database Description Packets in 791 Section 3.2.1.2. The sending of Link State Update Packets is 792 documented in Section 3.5.2. 794 3.2.1.1. Sending Hello packets 796 IPv6 changes the way OSPF Hello packets are sent in the 797 following ways (compare to Section 9.5 of [Ref1]): 799 o Before the Hello Packet is sent out an interface, 800 the interface's Interface ID must be copied into the 801 Hello Packet. 803 o The Hello Packet no longer contains an IP network 804 mask, as OSPF for IPv6 runs per-link instead of 805 per-subnet. 807 o The choice of Designated Router and Backup 808 Designated Router are now indicated within Hellos by 809 their Router IDs, instead of by their IP interface 810 addresses. Advertising the Designated Router (or 811 Backup Designated Router) as 0.0.0.0 indicates that 812 the Designated Router (or Backup Designated Router) 813 has not yet been chosen. 815 o The Options field within Hello packets has moved 816 around, getting larger in the process. More options 817 bits are now possible. Those that must be set 818 correctly in Hello packets are: The E-bit is set if 819 and only if the interface attaches to a non-stub 820 area, the N-bit is set if and only if the interface 821 attaches to an NSSA area (see [Ref9]), and the DC- 822 bit is set if and only if the router wishes to 823 suppress the sending of future Hellos over the 824 interface (see [Ref11]). Unrecognized bits in the 825 Hello Packet's Options field should be cleared. 827 Sending Hello packets on NBMA networks proceeds for IPv6 828 in exactly the same way as for IPv4, as documented in 829 Section 9.5.1 of [Ref1]. 831 3.2.1.2. Sending Database Description Packets 833 The sending of Database Description packets differs from 834 Section 10.8 of [Ref1] in the following ways: 836 o The Options field within Database Description 837 packets has moved around, getting larger in the 838 process. More options bits are now possible. Those 839 that must be set correctly in Database Description 840 packets are: The MC-bit is set if and only if the 841 router is forwarding multicast datagrams according 842 to the MOSPF specification in [Ref7]. Unrecognized 843 bits in the Database Description Packet's Options 844 field should be cleared. 846 3.2.2. Receiving protocol packets 848 Whenever an OSPF protocol packet is received by the router 849 it is marked with the interface it was received on. For 850 routers that have virtual links configured, it may not be 851 immediately obvious which interface to associate the packet 852 with. For example, consider the Router RT11 depicted in 853 Figure 6 of [Ref1]. If RT11 receives an OSPF protocol 854 packet on its interface to Network N8, it may want to 855 associate the packet with the interface to Area 2, or with 856 the virtual link to Router RT10 (which is part of the 857 backbone). In the following, we assume that the packet is 858 initially associated with the non-virtual link. 860 In order for the packet to be passed to OSPF for processing, 861 the following tests must be performed on the encapsulating 862 IPv6 headers: 864 o The packet's IP destination address must be one of the 865 IPv6 unicast addresses associated with the receiving 866 interface (this includes link-local addresses), or one 867 of the IP multicast addresses AllSPFRouters or 868 AllDRouters. 870 o The Next Header field of the immediately encapsulating 871 IPv6 header must specify the OSPF protocol (89). 873 o Any encapsulating IP Authentication Headers (see 874 [Ref19]) and the IP Encapsulating Security Payloads (see 875 [Ref20]) must be processed and/or verified to ensure 876 integrity and authentication/confidentiality of OSPF 877 routing exchanges. 879 o Locally originated packets should not be passed on to 880 OSPF. That is, the source IPv6 address should be 881 examined to make sure this is not a multicast packet 882 that the router itself generated. 884 After processing the encapsulating IPv6 headers, the OSPF 885 packet header is processed. The fields specified in the 886 header must match those configured for the receiving 887 interface. If they do not, the packet should be discarded: 889 o The version number field must specify protocol version 890 3. 892 o The standard IPv6 16-bit one's complement checksum, 893 covering the entire OSPF packet and prepended IPv6 894 pseudo-header, must be verified (see Section A.3.1). 896 o The Area ID found in the OSPF header must be verified. 897 If both of the following cases fail, the packet should 898 be discarded. The Area ID specified in the header must 899 either: 901 (1) Match the Area ID of the receiving interface. In 902 this case, unlike for IPv4, the IPv6 source address 903 is not restricted to lie on the same IP subnet as 904 the receiving interface. IPv6 OSPF runs per-link, 905 instead of per-IP-subnet. 907 (2) Indicate the backbone. In this case, the packet has 908 been sent over a virtual link. The receiving router 909 must be an area border router, and the Router ID 910 specified in the packet (the source router) must be 911 the other end of a configured virtual link. The 912 receiving interface must also attach to the virtual 913 link's configured Transit area. If all of these 914 checks succeed, the packet is accepted and is from 915 now on associated with the virtual link (and the 916 backbone area). 918 o The Instance ID specified in the OSPF header must match 919 the receiving interface's Instance ID. 921 o Packets whose IP destination is AllDRouters should only 922 be accepted if the state of the receiving interface is 923 DR or Backup (see Section 9.1). 925 After header processing, the packet is further processed 926 according to it OSPF packet type. OSPF packet types and 927 functions are the same for both IPv4 and IPv6. 929 If the packet type is Hello, it should then be further 930 processed by the Hello Protocol. All other packet types are 931 sent/received only on adjacencies. This means that the 932 packet must have been sent by one of the router's active 933 neighbors. The neighbor is identified by the Router ID 934 appearing the the received packet's OSPF header. Packets not 935 matching any active neighbor are discarded. 937 The receive processing of Database Description Packets, Link 938 State Request Packets and Link State Acknowledgment Packets 939 remains unchanged from the IPv4 procedures documented in 940 Sections 10.6, 10.7 and 13.7 of [Ref1] respectively. The 941 receiving of Hello Packets is documented in Section 3.2.2.1, 942 and the receiving of Link State Update Packets is documented 943 in Section 3.5.1. 945 3.2.2.1. Receiving Hello Packets 947 The receive processing of Hello Packets differs from 948 Section 10.5 of [Ref1] in the following ways: 950 o On all link types (e.g., broadcast, NBMA, point-to- 951 point, etc), neighbors are identified solely by 952 their OSPF Router ID. For all link types except 953 virtual links, the Neighbor IP address is set to the 954 IPv6 source address in the IPv6 header of the 955 received OSPF Hello packet. 957 o There is no longer a Network Mask field in the Hello 958 Packet. 960 o The neighbor's choice of Designated Router and 961 Backup Designated Router is now encoded as an OSPF 962 Router ID instead of an IP interface address. 964 3.3. The Routing table Structure 966 The routing table used by OSPF for IPv4 is defined in Section 11 967 of [Ref1]. For IPv6 there are analogous routing table entries: 968 there are routing table entries for IPv6 address prefixes, and 969 also for AS boundary routers. The latter routing table entries 970 are only used to hold intermediate results during the routing 971 table build process (see Section 3.8). 973 Also, to hold the intermediate results during the shortest-path 974 calculation for each area, there is a separate routing table for 975 each area holding the following entries: 977 o An entry for each router in the area. Routers are identified 978 by their OSPF router ID. These routing table entries hold 979 the set of shortest paths through a given area to a given 980 router, which in turn allows calculation of paths to the 981 IPv6 prefixes advertised by that router in Intra-area- 982 prefix-LSAs. If the router is also an area-border router, 983 these entries are also used to calculate paths for inter- 984 area address prefixes. If in addition the router is the 985 other endpoint of a virtual link, the routing table entry 986 describes the cost and viability of the virtual link. 988 o An entry for each transit link in the area. Transit links 989 have associated network-LSAs. Both the transit link and the 990 network-LSA are identified by a combination of the 991 Designated Router's Interface ID on the link and the 992 Designated Router's OSPF Router ID. These routing table 993 entries allow later calculation of paths to IP prefixes 994 advertised for the transit link in intra-area-prefix-LSAs. 996 Since IPv6 does not support the concept of Type of Service 997 (TOS), there are no longer separate sets of paths for each TOS. 998 The rest of the fields in the IPv4 OSPF routing table (see 999 Section 11 of [Ref1]) remain valid for IPv6: Optional 1000 capabilities (routers only), path type, cost, type 2 cost, link 1001 state origin, and for each of the equal cost paths to the 1002 destination, the next hop and advertising router (inter-area and 1003 AS external paths only). 1005 For IPv6, the link-state origin field in the routing table entry 1006 is the router-LSA or network-LSA that has directly or indirectly 1007 produced the routing table entry. For example, if the routing 1008 table entry describes a route to an IPv6 prefix, the link state 1009 origin is the router-LSA or network-LSA that is listed in the 1010 body of the intra-area-prefix-LSA that has produced the route 1011 (see Section A.4.9). 1013 3.3.1. Routing table lookup 1015 Routing table lookup (i.e., determining the best matching 1016 routing table entry during IP forwarding) is the same for 1017 IPv6 as for IPv4, except that Type of Service is not taken 1018 into account. The lookup consists of the first three steps 1019 of Section 11.1 in [Ref1], ignoring the last step that 1020 concerns only TOS. 1022 3.4. Link State Advertisements 1024 For IPv6, the OSPF LSA header has changed slightly, with the LS 1025 type field expanding and the Options field being moved into the 1026 body of appropriate LSAs. Also, the formats of some LSAs have 1027 changed somewhat (namely router-LSAs, network-LSAs and AS- 1028 external-LSAs), while the names of other LSAs have been changed 1029 (type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and 1030 inter-area-router-LSAs respectively) and additional LSAs have 1031 been added (Link-LSAs and Intra-Area-Prefix-LSAs). Since IPv6 1032 does not support TOS, TOS is no longer encoded within LSAs. 1034 These changes will be described in detail in the following 1035 subsections. 1037 3.4.1. The LSA Header 1039 In both IPv4 and IPv6, all OSPF LSAs begin with a standard 1040 20 byte LSA header. However, the contents of this 20 byte 1041 header have changed in IPv6. The LS age, Advertising Router, 1042 LS Sequence Number, LS checksum and length fields within the 1043 LSA header remain unchanged, as documented in Sections 1044 12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1 of [Ref1] 1045 respectively. However, the following fields have changed 1046 for IPv6: 1048 Options 1049 The Options field has been removed from the standard 20 1050 byte LSA header, and into the body of router-LSAs, 1051 network-LSAs, inter-area-router-LSAs and link-LSAs. The 1052 size of the Options field has increased from 8 to 24 1053 bits, and some of the bit definitions have changed (see 1054 Section A.2). In addition a separate PrefixOptions 1055 field, 8 bits in length, is attached to each prefix 1056 advertised within the body of an LSA. 1058 LS type 1059 The size of the LS type field has increased from 8 to 16 1060 bits, with the top two bits encoding flooding scope and 1061 the next bit encoding the handling of unknown LS types. 1062 See Section A.4.2.1 for the current coding of the LS 1063 type field. 1065 Link State ID 1066 Link State ID remains at 32 bits in length, but except 1067 for network-LSAs and link-LSAs, Link State ID has shed 1068 any addressing semantics. For example, an IPv6 router 1069 originating multiple AS-external-LSAs could start by 1070 assigning the first a Link State ID of 0.0.0.1, the 1071 second a Link State ID of 0.0.0.2, and so on. Instead of 1072 the IPv4 behavior of encoding the network number within 1073 the AS-external-LSA's Link State ID, the IPv6 Link State 1074 ID simply serves as a way to differentiate multiple LSAs 1075 originated by the same router. 1077 For network-LSAs, the Link State ID is set to the 1078 Designated Router's Interface ID on the link. When a 1079 router originates a Link-LSA for a given link, its Link 1080 State ID is set equal to the router's Interface ID on 1081 the link. 1083 3.4.2. The link-state database 1085 In IPv6, as in IPv4, individual LSAs are identified by a 1086 combination of their LS type, Link State ID and Advertising 1087 Router fields. Given two instances of an LSA, the most 1088 recent instance is determined by examining the LSAs' LS 1089 Sequence Number, using LS checksum and LS age as tiebreakers 1090 (see Section 13.1 of [Ref1]). 1092 In IPv6, the link-state database is split across three 1093 separate data structures. LSAs with AS flooding scope are 1094 contained within the top-level OSPF data structure (see 1095 Section 3.1) as long as either their LS type is known or 1096 their U-bit is 1 (flood even when unrecognized); this 1097 includes the AS-external-LSAs. LSAs with area flooding scope 1098 are contained within the appropriate area structure (see 1099 Section 3.1.1) as long as either their LS type is known or 1100 their U-bit is 1 (flood even when unrecognized); this 1101 includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, 1102 inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs 1103 with unknown LS type and U-bit set to 0 and/or link-local 1104 flooding scope are contained within the appropriate 1105 interface structure (see Section 3.1.2); this includes 1106 link-LSAs. 1108 To lookup or install an LSA in the database, you first 1109 examine the LS type and the LSA's context (i.e., to which 1110 area or link does the LSA belong). This information allows 1111 you to find the correct list of LSAs, all of the same LS 1112 type, where you then search based on the LSA's Link State ID 1113 and Advertising Router. 1115 3.4.3. Originating LSAs 1117 The process of reoriginating an LSA in IPv6 is the same as 1118 in IPv4: the LSA's LS sequence number is incremented, its 1119 LS age is set to 0, its LS checksum is calculated, and the 1120 LSA is added to the link state database and flooded out the 1121 appropriate interfaces. 1123 To the list of events causing LSAs to be reoriginated, which 1124 for IPv4 is given in Section 12.4 of [Ref1], the following 1125 events are added for IPv6: 1127 o The Interface ID of a neighbor changes. This may cause a 1128 new instance of a router-LSA to be originated for the 1129 associated area. 1131 o A new prefix is added to an attached link, or a prefix 1132 is deleted (both through configuration). This causes the 1133 router to reoriginate its link-LSA for the link, or, if 1134 it is the only router attached to the link, causes the 1135 router to reoriginate an intra-area-prefix-LSA. 1137 o A new link-LSA is received, causing the link's 1138 collection of prefixes to change. If the router is 1139 Designated Router for the link, it originates a new 1140 intra-area-prefix-LSA. 1142 Detailed construction of the seven required IPv6 LSA types 1143 is supplied by the following subsections. In order to 1144 display example LSAs, the network map in Figure 15 of [Ref1] 1145 has been reworked to show IPv6 addressing, resulting in 1146 Figure 1. The OSPF cost of each interface is has been 1147 displayed in Figure 1. The assignment of IPv6 prefixes to 1148 network links is shown in Table 1. A single area address 1149 range has been configured for Area 1, so that outside of 1150 Area 1 all of its prefixes are covered by a single route to 1151 5f00:0000:c001::/48. The OSPF interface IDs and the link- 1152 local addresses for the router interfaces in Figure 1 are 1153 given in Table 2. 1155 .......................................... 1156 . Area 1. 1157 . + . 1158 . | . 1159 . | 3+---+1 . 1160 . N1 |--|RT1|-----+ . 1161 . | +---+ \ . 1162 . | \ ______ . 1163 . + \/ \ 1+---+ 1164 . * N3 *------|RT4|------ 1165 . + /\_______/ +---+ 1166 . | / | . 1167 . | 3+---+1 / | . 1168 . N2 |--|RT2|-----+ 1| . 1169 . | +---+ +---+ . 1170 . | |RT3|---------------- 1171 . + +---+ . 1172 . |2 . 1173 . | . 1174 . +------------+ . 1175 . N4 . 1176 .......................................... 1178 Figure 1: Area 1 with IP addresses shown 1180 Network IPv6 prefix 1181 __________________________________ 1182 N1 5f00:0000:0c01:0200::/56 1183 N2 5f00:0000:0c01:0300::/56 1184 N3 5f00:0000:0c01:0100::/56 1185 N4 5f00:0000:0c01:0400::/56 1187 Table 1: IPv6 link prefixes for sample network 1188 Router interface Interface ID link-local address 1189 ______________________________________________________ 1190 RT1 to N1 1 fe80:0001::RT1 1191 to N3 2 fe80:0002::RT1 1192 RT2 to N2 1 fe80:0001::RT2 1193 to N3 2 fe80:0002::RT2 1194 RT3 to N3 1 fe80:0001::RT3 1195 to N4 2 fe80:0002::RT3 1196 RT4 to N3 1 fe80:0001::RT4 1198 Table 2: OSPF Interface IDs and link-local addresses 1200 3.4.3.1. Router-LSAs 1202 The LS type of a router-LSA is set to the value 0x2001. 1203 Router-LSAs have area flooding scope. A router may 1204 originate one or more router-LSAs for a given area. 1205 Taken together, the collection of router-LSAs originated 1206 by the router for an area describes the collected states 1207 of all the router's interface to the area. When multiple 1208 router-LSAs are used, they are distinguished by their 1209 Link State ID fields. 1211 The Options field in the router-LSA should be coded as 1212 follows. The V6-bit should be set. The E-bit should be 1213 clear if and only if the area is an OSPF stub area. The 1214 MC-bit should be set if and only if the router is 1215 running MOSPF (see [Ref8]). The N-bit should be set if 1216 and only if the area is an OSPF NSSA area. The R-bit 1217 should be set. The DC-bit should be set if and only if 1218 the router can correctly process the DoNotAge bit when 1219 it appears in the LS age field of LSAs (see [Ref11]). 1220 All unrecognized bits in the Options field should be 1221 cleared 1223 To the left of the Options field, the router capability 1224 bits V, E and B should be coded according to Section 1225 12.4.1 of [Ref1]. Bit W should be coded according to 1226 [Ref8]. 1228 Each of the router's interfaces to the area are then 1229 described by appending "link descriptions" to the 1230 router-LSA. Each link description is 16 bytes long, 1231 consisting of 5 fields: (link) Type, Metric, Interface 1232 ID, Neighbor Interface ID and Neighbor Router ID (see 1233 Section A.4.3). Interfaces in state "Down" or "Loopback" 1234 are not described (although looped back interfaces can 1235 contribute prefixes to Intra-Area-Prefix-LSAs). Nor are 1236 interfaces without any full adjacencies described. All 1237 other interfaces to the area add zero, one or more link 1238 descriptions, the number and content of which depend on 1239 the interface type. Within each link description, the 1240 Metric field is always set the interface's output cost 1241 and the Interface ID field is set to the interface's 1242 OSPF Interface ID. 1244 Point-to-point interfaces 1245 If the neighboring router is fully adjacent, add a 1246 Type 1 link description (point-to-point). The 1247 Neighbor Interface ID field is set to the Interface 1248 ID advertised by the neighbor in its Hello packets, 1249 and the Neighbor Router ID field is set to the 1250 neighbor's Router ID. 1252 Broadcast and NBMA interfaces 1253 If the router is fully adjacent to the link's 1254 Designated Router, or if the router itself is 1255 Designated Router and is fully adjacent to at least 1256 one other router, add a single Type 2 link 1257 description (transit network). The Neighbor 1258 Interface ID field is set to the Interface ID 1259 advertised by the Designated Router in its Hello 1260 packets, and the Neighbor Router ID field is set to 1261 the Designated Router's Router ID. 1263 Virtual links 1264 If the neighboring router is fully adjacent, add a 1265 Type 4 link description (virtual). The Neighbor 1266 Interface ID field is set to the Interface ID 1267 advertised by the neighbor in its Hello packets, and 1268 the Neighbor Router ID field is set to the 1269 neighbor's Router ID. Note that the output cost of a 1270 virtual link is calculated during the routing table 1271 calculation (see Section 3.7). 1273 Point-to-MultiPoint interfaces 1274 For each fully adjacent neighbor associated with the 1275 interface, add a separate Type 1 link description 1276 (point-to-point) with Neighbor Interface ID field 1277 set to the Interface ID advertised by the neighbor 1278 in its Hello packets, and Neighbor Router ID field 1279 set to the neighbor's Router ID. 1281 As an example, consider the router-LSA that router RT3 1282 would originate for Area 1 in Figure 1. Only a single 1283 interface must be described, namely that which connects 1284 to the transit network N3. It assumes that RT4 has bee 1285 elected Designated Router of Network N3. 1287 ; RT3's router-LSA for Area 1 1289 LS age = 0 ;newly (re)originated 1290 LS type = 0x2001 ;router-LSA 1291 Link State ID = 0 ;first fragment 1292 Advertising Router = 192.1.1.3 ;RT3's Router ID 1293 bit E = 0 ;not an AS boundary router 1294 bit B = 1 ;area border router 1295 Options = (V6-bit|E-bit|R-bit) 1296 Type = 2 ;connects to N3 1297 Metric = 1 ;cost to N3 1298 Interface ID = 1 ;RT3's Interface ID on N3 1299 Neighbor Interface ID = 1 ;RT4's Interface ID on N3 1300 Neighbor Router ID = 192.1.1.4 ; RT4's Router ID 1302 If for example another router was added to Network N4, 1303 RT3 would have to advertise a second link description 1304 for its connection to (the now transit) network N4. This 1305 could be accomplished by reoriginating the above 1306 router-LSA, this time with two link descriptions. Or, a 1307 separate router-LSA could be originated with a separate 1308 Link State ID (e.g., using a Link State ID of 1) to 1309 describe the connection to N4. 1311 Host routes no longer appear in the router-LSA, but are 1312 instead included in intra-area-prefix-LSAs. 1314 3.4.3.2. Network-LSAs 1316 The LS type of a network-LSA is set to the value 0x2002. 1317 Network-LSAs have area flooding scope. A network-LSA is 1318 originated for every transit broadcast or NBMA link, by 1319 the link's Designated Router. Transit links are those 1320 that have two or more attached routers. The network-LSA 1321 lists all routers attached to the link. 1323 The procedure for originating network-LSAs in IPv6 is 1324 the same as the IPv4 procedure documented in Section 1325 12.4.2 of [Ref1], with the following exceptions: 1327 o An IPv6 network-LSA's Link State ID is set to the 1328 Interface ID of the Designated Router on the link. 1330 o IPv6 network-LSAs do not contain a Network Mask. All 1331 addressing information formerly contained in the 1332 IPv4 network-LSA has now been consigned to intra- 1333 Area-Prefix-LSAs. 1335 o The Options field in the network-LSA is set to the 1336 logical OR of the Options fields contained within 1337 the link's associated link-LSAs. In this way, the 1338 network link exhibits a capability when at least one 1339 of the link's routers requests that the capability 1340 be asserted. 1342 As an example, assuming that Router RT4 has been elected 1343 Designated Router of Network N3 in Figure 1, the 1344 following network-LSA is originated: 1346 ; Network-LSA for Network N3 1348 LS age = 0 ;newly (re)originated 1349 LS type = 0x2002 ;network-LSA 1350 Link State ID = 1 ;RT4's Interface ID on N3 1351 Advertising Router = 192.1.1.4 ;RT4's Router ID 1352 Options = (V6-bit|E-bit|R-bit) 1353 Attached Router = 192.1.1.4 ;Router ID 1354 Attached Router = 192.1.1.1 ;Router ID 1355 Attached Router = 192.1.1.2 ;Router ID 1356 Attached Router = 192.1.1.3 ;Router ID 1358 3.4.3.3. Inter-Area-Prefix-LSAs 1360 The LS type of an inter-area-prefix-LSA is set to the 1361 value 0x2003. Inter-area-prefix-LSAs have area flooding 1362 scope. In IPv4, inter-area-prefix-LSAs were called type 1363 3 summary-LSAs. Each inter-area-prefix-LSA describes a 1364 prefix external to the area, yet internal to the 1365 Autonomous System. 1367 The procedure for originating inter-area-prefix-LSAs in 1368 IPv6 is the same as the IPv4 procedure documented in 1369 Sections 12.4.3 and 12.4.3.1 of [Ref1], with the 1370 following exceptions: 1372 o The Link State ID of an inter-area-prefix-LSA has 1373 lost all of its addressing semantics, and instead 1374 simply serves to distinguish multiple inter-area- 1375 prefix-LSAs that are originated by the same router. 1377 o The prefix is described by the PrefixLength, 1378 PrefixOptions and Address Prefix fields embedded 1379 within the LSA body. Network Mask is no longer 1380 specified. 1382 o The NU-bit in the PrefixOptions field should be 1383 clear. The coding of the MC-bit depends upon 1384 whether, and if so how, MOSPF is operating in the 1385 routing domain (see [Ref8]). 1387 o Link-local addresses can never be advertised in 1388 inter-area-prefix-LSAs. 1390 As an example, the following shows the inter-area- 1391 prefix-LSA that Router RT4 originates into the OSPF 1392 backbone area, condensing all of Area 1's prefixes into 1393 the single prefix 5f00:0000:c001::/48. The cost is set 1394 to 4, which is the maximum cost to all of the prefix' 1395 individual components. The prefix is padded out to an 1396 even number of 32-bit words, so that it consumes 64-bits 1397 of space instead of 48 bits. 1399 ; Inter-area-prefix-LSA for Area 1 addresses 1400 ; originated by Router RT4 into the backbone 1402 LS age = 0 ;newly (re)originated 1403 LS type = 0x2003 ;inter-area-prefix-LSA 1404 Advertising Router = 192.1.1.4 ;RT4's ID 1405 Metric = 4 ;maximum to components 1406 PrefixLength = 48 1407 PrefixOptions = 0 1408 Address Prefix = 5f00:0000:c001 ;padded to 64-bits 1410 3.4.3.4. Inter-Area-Router-LSAs 1412 The LS type of an inter-area-router-LSA is set to the 1413 value 0x2004. Inter-area-router-LSAs have area flooding 1414 scope. In IPv4, inter-area-router-LSAs were called type 1415 4 summary-LSAs. Each inter-area-router-LSA describes a 1416 path to a destination OSPF router (an ASBR) that is 1417 external to the area, yet internal to the Autonomous 1418 System. 1420 The procedure for originating inter-area-router-LSAs in 1421 IPv6 is the same as the IPv4 procedure documented in 1422 Section 12.4.3 of [Ref1], with the following exceptions: 1424 o The Link State ID of an inter-area-router-LSA is no 1425 longer the destination router's OSPF Router ID, but 1426 instead simply serves to distinguish multiple 1427 inter-area-router-LSAs that are originated by the 1428 same router. The destination router's Router ID is 1429 now found in the body of the LSA. 1431 o The Options field in an inter-area-router-LSA should 1432 be set equal to the Options field contained in the 1433 destination router's own router-LSA. The Options 1434 field thus describes the capabilities supported by 1435 the destination router. 1437 As an example, consider the OSPF Autonomous System 1438 depicted in Figure 6 of [Ref1]. Router RT4 would 1439 originate into Area 1 the following inter-area-router- 1440 LSA for destination router RT7. 1442 ; inter-area-router-LSA for AS boundary router RT7 1443 ; originated by Router RT4 into Area 1 1445 LS age = 0 ;newly (re)originated 1446 LS type = 0x2004 ;inter-area-router-LSA 1447 Advertising Router = 192.1.1.4 ;RT4's ID 1448 Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities 1449 Metric = 14 ;cost to RT7 1450 Destination Router ID = Router RT7's ID 1452 3.4.3.5. AS-external-LSAs 1454 The LS type of an AS-external-LSA is set to the value 1455 0x4005. AS-external-LSAs have AS flooding scope. Each 1456 AS-external-LSA describes a path to a prefix external to 1457 the Autonomous System. 1459 The procedure for originating AS-external-LSAs in IPv6 1460 is the same as the IPv4 procedure documented in Section 1461 12.4.4 of [Ref1], with the following exceptions: 1463 o The Link State ID of an AS-external-LSA has lost all 1464 of its addressing semantics, and instead simply 1465 serves to distinguish multiple AS-external-LSAs that 1466 are originated by the same router. 1468 o The prefix is described by the PrefixLength, 1469 PrefixOptions and Address Prefix fields embedded 1470 within the LSA body. Network Mask is no longer 1471 specified. 1473 o The NU-bit in the PrefixOptions field should be 1474 clear. The coding of the MC-bit depends upon 1475 whether, and if so how, MOSPF is operating in the 1476 routing domain (see [Ref8]). 1478 o Link-local addresses can never be advertised in AS- 1479 external-LSAs. 1481 o The forwarding address is present in the AS- 1482 external-LSA if and only if the AS-external-LSA's 1483 bit F is set. 1485 o The external route tag is present in the AS- 1486 external-LSA if and only if the AS-external-LSA's 1487 bit T is set. 1489 o The capability for an AS-external-LSA to reference 1490 another LSA has been included, by inclusion of the 1491 Referenced LS Type field and the optional Referenced 1492 Link State ID field (the latter present if and only 1493 if Referenced LS Type is non-zero). This capability 1494 is for future use; for now Referenced LS Type should 1495 be set to 0. 1497 As an example, consider the OSPF Autonomous System 1498 depicted in Figure 6 of [Ref1]. Assume that RT7 has 1499 learned its route to N12 via BGP, and that it wishes to 1500 advertise a Type 2 metric into the AS. Further assume 1501 the the IPv6 prefix for N12 is the value 1502 5f00:0000:0a00::/40. RT7 would then originate the 1503 following AS-external-LSA for the external network N12. 1504 Note that within the AS-external-LSA, N12's prefix 1505 occupies 64 bits of space, to maintain 32-bit alignment. 1507 ; AS-external-LSA for Network N12, 1508 ; originated by Router RT7 1510 LS age = 0 ;newly (re)originated 1511 LS type = 0x4005 ;AS-external-LSA 1512 Link State ID = 123 ;or something else 1513 Advertising Router = Router RT7's ID 1514 bit E = 1 ;Type 2 metric 1515 bit F = 0 ;no forwarding address 1516 bit T = 1 ;external route tag included 1517 Metric = 2 1518 PrefixLength = 40 1519 PrefixOptions = 0 1520 Referenced LS Type = 0 ;no Referenced Link State ID 1521 Address Prefix = 5f00:0000:0a00 ;padded to 64-bits 1522 External Route Tag = as per BGP/OSPF interaction 1524 3.4.3.6. Link-LSAs 1526 The LS type of a Link-LSA is set to the value 0x0008. 1527 Link-LSAs have link-local flooding scope. A router 1528 originates a separate Link-LSA for each attached link 1529 that supports 2 or more (including the originating 1530 router itself) routers. 1532 Link-LSAs have three purposes: 1) they provide the 1533 router's link-local address to all other routers 1534 attached to the link and 2) they inform other routers 1535 attached to the link of a list of IPv6 prefixes to 1536 associate with the link and 3) they allow the router to 1537 assert a collection of Options bits in the Network-LSA 1538 that will be originated for the link. 1540 A Link-LSA for a given Link L is built in the following 1541 fashion: 1543 o The Link State ID is set to the router's Interface 1544 ID on Link L. 1546 o The Router Priority of the router's interface to 1547 Link L is inserted into the Link-LSA. 1549 o The Link-LSA's Options field is set to those bits 1550 that the router wishes set in Link L's Network LSA. 1552 o The router inserts its link-local address on Link L 1553 into the Link-LSA. This information will be used 1554 when the other routers on Link L do their next hop 1555 calculations (see Section 3.8.1.1). 1557 o Each IPv6 address prefix that has been configured 1558 into the router for Link L is added to the Link-LSA, 1559 by specifying values for PrefixLength, 1560 PrefixOptions, and Address Prefix fields. 1562 After building a Link-LSA for a given link, the router 1563 installs the link-LSA into the associate interface data 1564 structure and floods the Link-LSA onto the link. All 1565 other routers on the link will receive the Link-LSA, but 1566 it will go no further. 1568 As an example, consider the Link-LSA that RT3 will build 1569 for N3 in Figure 1. Suppose that the prefix 1570 5f00:0000:0c01:0100::/56 has been configured within RT3 1571 for N3. This will give rise to the following Link-LSA, 1572 which RT3 will flood onto N3, but nowhere else. Note 1573 that not all routers on N3 need be configured with the 1574 prefix; those not configured will learn the prefix when 1575 receiving RT3's Link-LSA. 1577 ; RT3's Link-LSA for N3 1579 LS age = 0 ;newly (re)originated 1580 LS type = 0x0008 ;Link-LSA 1581 Link State ID = 1 ;RT3's Interface ID on N3 1582 Advertising Router = 192.1.1.3 ;RT3's Router ID 1583 Rtr Pri = 1 ;RT3's N3 Router Priority 1584 Options = (V6-bit|E-bit|R-bit) 1585 Link-local Interface Address = fe80:0001::RT3 1586 # prefixes = 1 1587 PrefixLength = 56 1588 PrefixOptions = 0 1589 Address Prefix = 5f00:0000:c001:0100 ;pad to 64-bits 1591 3.4.3.7. Intra-Area-Prefix-LSAs 1593 The LS type of an intra-area-prefix-LSA is set to the 1594 value 0x2009. Intra-area-prefix-LSAs have area flooding 1595 scope. An intra-area-prefix-LSA has one of two 1596 functions. It associates a list of IPv6 address prefixes 1597 with a transit network link by referencing a network- 1598 LSA, or associates a list of IPv6 address prefixes with 1599 a router by referencing a router-LSA. A sub network 1600 link's prefixes are associated with its attached router. 1602 A router may originate multiple intra-area-prefix-LSAs 1603 for a given area, distinguished by their Link State ID 1604 fields. 1606 A network link's Designated Router originates an intra- 1607 area-prefix-LSA to advertise the link's prefixes 1608 throughout the area. For a link L, L's Designated Router 1609 builds an intra-area-prefix-LSA in the following 1610 fashion: 1612 o In order to indicate that the prefixes are to be 1613 associated with the Link L, the fields Referenced LS 1614 type, Referenced Link State ID, and Referenced 1615 Advertising Router are set to the corresponding 1616 fields in Link L's Network LSA (namely LS type, Link 1617 State ID, and Advertising Router respectively). This 1618 means that Referenced LS Type is set to 0x2002, 1619 Referenced Link State ID is set to the Designated 1620 Router's Interface ID on Link L, and Referenced 1621 Advertising Router is set to the Designated Router's 1622 Router ID. 1624 o Each Link-LSA associated with Link L is examined 1625 (these are in the Designated Router's interface 1626 structure for Link L). If the Link-LSA's Advertising 1627 Router is fully adjacent to the Designated Router, 1628 the list of prefixes in the Link-LSA is copied into 1629 the intra-area-prefix-LSA that is being built. 1630 Prefixes having the NU-bit and/or LA-bit set in 1631 their Options field should not be copied, nor should 1632 link-local addresses be copied. Each prefix is 1633 described by the PrefixLength, PrefixOptions, and 1634 Address Prefix fields. Multiple prefixes having the 1635 same PrefixLength and Address Prefix are considered 1636 to be duplicates; in this case their Prefix Options 1637 fields should be merged by logically OR'ing the 1638 fields together, and a single resulting prefix 1639 should be copied into the intra-area-prefix-LSA. The 1640 Metric field for all prefixes is set to 0. 1642 o The "# prefixes" field is set to the number of 1643 prefixes that the router has copied into the LSA. If 1644 necessary, the list of prefixes can be spread across 1645 multiple intra-area-prefix-LSAs in order to keep the 1646 LSA size small. 1648 A router builds an intra-area-prefix-LSA to advertise 1649 its own prefixes, and those of its attached stub network 1650 links. A Router RTX would build its intra-area-prefix- 1651 LSA in the following fashion: 1653 o In order to indicate that the prefixes are to be 1654 associated with the Router RTX itself, RTX sets 1655 Referenced LS type to 0x2001, Referenced Link State 1656 ID to 0, and Referenced Advertising Router to RTX's 1657 own Router ID. 1659 o Router RTX examines its list of interfaces to the 1660 area. If the interface is in state Down, its 1661 prefixes are not included. If the interface has been 1662 reported in RTX's router-LSA as a Type 2 link 1663 description (link to transit network), its prefixes 1664 are not included (they will be included in the 1665 intra-area-prefix-LSA for the link instead). If the 1666 interface type is point-to-point or Point-to- 1667 MultiPoint, or the interface is in state Loopback, 1668 the site-local and global scope IPv6 addresses 1669 associated with the interface (if any) are copied 1670 into the intra-area-prefix-LSA, setting the LA-bit 1671 in the PrefixOptions field, and setting the 1672 PrefixLength to 128 and the Metric to 0. Otherwise, 1673 the list of site-local and global prefixes 1674 configured in RTX for the link are copied into the 1675 intra-area-prefix-LSA by specifying the 1676 PrefixLength, PrefixOptions, and Address Prefix 1677 fields. The Metric field for each of these prefixes 1678 is set to the interface's output cost. 1680 o RTX adds the IPv6 prefixes for any directly attached 1681 hosts (see Section C.7) to the intra-area-prefix- 1682 LSA. 1684 o If RTX has one or more virtual links configured 1685 through the area, it includes one of its site-local 1686 or global scope IPv6 interface addresses in the LSA 1687 (if it hasn't already), setting the LA-bit in the 1688 PrefixOptions field, and setting the PrefixLength to 1689 128 and the Metric to 0. This information will be 1690 used later in the routing calculation so that the 1691 two ends of the virtual link can discover each 1692 other's IPv6 addresses. 1694 o The "# prefixes" field is set to the number of 1695 prefixes that the router has copied into the LSA. If 1696 necessary, the list of prefixes can be spread across 1697 multiple intra-area-prefix-LSAs in order to keep the 1698 LSA size small. 1700 For example, the intra-area-prefix-LSA originated by RT4 1701 for Network N3 (assuming that RT4 is N3's Designated 1702 Router), and the intra-area-prefix-LSA originated into 1703 Area 1 by Router RT3 for its own prefixes, are pictured 1704 below. 1706 ; Intra-area-prefix-LSA 1707 ; for network link N3 1709 LS age = 0 ;newly (re)originated 1710 LS type = 0x2009 ;Link-LSA 1711 Link State ID = 5 ;or something 1712 Advertising Router = 192.1.1.4 ;RT4's Router ID 1713 # prefixes = 1 1714 Referenced LS type = 0x2002 ;network-LSA reference 1715 Referenced Link State ID = 1 1716 Referenced Advertising Router = 192.1.1.4 1717 PrefixLength = 56 ;N3's prefix 1718 PrefixOptions = 0 1719 Metric = 0 1720 Address Prefix = 5f00:0000:c001:0100 ;pad 1722 ; RT3's Intra-area-prefix-LSA 1723 ; for its own prefixes 1725 LS age = 0 ;newly (re)originated 1726 LS type = 0x2009 ;Link-LSA 1727 Link State ID = 177 ;or something 1728 Advertising Router = 192.1.1.3 ;RT3's Router ID 1729 # prefixes = 1 1730 Referenced LS type = 0x2001 ;router-LSA reference 1731 Referenced Link State ID = 0 1732 Referenced Advertising Router = 192.1.1.3 1733 PrefixLength = 56 ;N4's prefix 1734 PrefixOptions = 0 1735 Metric = 2 ;N4 interface cost 1736 Address Prefix = 5f00:0000:c001:0400 ;pad 1738 3.5. Flooding 1740 Most of the flooding algorithm remains unchanged from the IPv4 1741 flooding mechanisms described in Section 13 of [Ref1]. In 1742 particular, the processes for determining which LSA instance is 1743 newer (Section 13.1 of [Ref1]), responding to updates of self- 1744 originated LSAs (Section 13.4 of [Ref1]), sending Link State 1745 Acknowledgment packets (Section 13.5 of [Ref1]), retransmitting 1746 LSAs (Section 13.6 of [Ref1]) and receiving Link State 1747 Acknowledgment packets (Section 13.7 of [Ref1]) are exactly the 1748 same for IPv6 and IPv4. 1750 However, the addition of flooding scope and handling options for 1751 unrecognized LSA types (see Section A.4.2.1) has caused some 1752 changes in the OSPF flooding algorithm: the reception of Link 1753 State Updates (Section 13 in [Ref1]) and the sending of Link 1754 State Updates (Section 13.3 of [Ref1]) must take into account 1755 the LSA's scope and U-bit setting. Also, installation of LSAs 1756 into the OSPF database (Section 13.2 of [Ref1]) causes different 1757 events in IPv6, due to the reorganization of LSA types and 1758 contents in IPv6. These changes are described in detail below. 1760 3.5.1. Receiving Link State Update packets 1762 The encoding of flooding scope in the LS type and the need 1763 to process unknown LS types causes modifications to the 1764 processing of received Link State Update packets. As in 1765 IPv4, each LSA in a received Link State Update packet is 1766 examined. In IPv4, eight steps are executed for each LSA, as 1767 described in Section 13 of [Ref1]. For IPv6, all the steps 1768 are the same, except that Steps 2 and 3 are modified as 1769 follows: 1771 (2) Examine the LSA's LS type. If the LS type is unknown, 1772 the area has been configured as a stub area, and either 1773 the LSA's flooding scope is set to "AS flooding scope" 1774 or the U-bit of the LS type is set to 1 (flood even when 1775 unrecognized), then discard the LSA and get the next one 1776 from the Link State Update Packet. This generalizes the 1777 IPv4 behavior where AS-external-LSAs are not flooded 1778 into/throughout stub areas. 1780 (3) Else if the flooding scope of the LSA is set to 1781 "reserved", discard the LSA and get the next one from 1782 the Link State Update Packet. 1784 Steps 5b (sending Link State Update packets) and 5d 1785 (installing LSAs in the link state database) in Section 13 1786 of [Ref1] are also somewhat different for IPv6, as described 1787 in Sections 3.5.2 and 3.5.3 below. 1789 3.5.2. Sending Link State Update packets 1791 The sending of Link State Update packets is described in 1792 Section 13.3 of [Ref1]. For IPv4 and IPv6, the steps for 1793 sending a Link State Update packet are the same (steps 1 1794 through 5 of Section 13.3 in [Ref1]). However, the list of 1795 eligible interfaces out which to flood the LSA is different. 1796 For IPv6, the eligible interfaces are selected based on the 1797 following factors: 1799 o The LSA's flooding scope. 1801 o For LSAs with area or link-local flooding scoping, the 1802 particular area or interface that the LSA is associated 1803 with. 1805 o Whether the LSA has a recognized LS type. 1807 o The setting of the U-bit in the LS type. If the U-bit is 1808 set to 0, unrecognized LS types are treated as having 1809 link-local scope. If set to 1, unrecognized LS types are 1810 stored and flooded as if they were recognized. 1812 Choosing the set of eligible interfaces then breaks into the 1813 following cases: 1815 Case 1 1816 The LSA's LS type is recognized. In this case, the set 1817 of eligible interfaces is set depending on the flooding 1818 scope encoded in the LS type. If the flooding scope is 1819 "AS flooding scope", the eligible interfaces are all 1820 router interfaces excepting virtual links. In addition, 1821 AS-external-LSAs are not flooded out interfaces 1822 connecting to stub areas. If the flooding scope is "area 1823 flooding scope", the set of eligible interfaces are 1824 those interfaces connecting to the LSA's associated 1825 area. If the flooding scope is "link-local flooding 1826 scope", then there is a single eligible interface, the 1827 one connecting to the LSA's associated link (which, when 1828 the LSA is received in a Link State Update packet, is 1829 also the interface the LSA was received on). 1831 Case 2 1832 The LS type is unrecognized, and the U-bit in the LS 1833 Type is set to 0 (treat the LSA as if it had link-local 1834 flooding scope). In this case there is a single eligible 1835 interface, namely, the interface on which the LSA was 1836 received. 1838 Case 3 1839 The LS type is unrecognized, and the U-bit in the LS 1840 Type is set to 1 (store and flood the LSA, as if type 1841 understood). In this case, select the eligible 1842 interfaces based on the encoded flooding scope as in 1843 Case 1 above. However, in this case interfaces attached 1844 to stub areas are always excluded. 1846 A further decision must sometimes be made before adding an 1847 LSA to a given neighbor's link-state retransmission list 1848 (Step 1d in Section 13.3 of [Ref1]). If the LS type is 1849 recognized by the router, but not by the neighbor (as can be 1850 determined by examining the Options field that the neighbor 1851 advertised in its Database Description packet) and the LSA's 1852 U-bit is set to 0, then the LSA should be added to the 1853 neighbor's link-state retransmission list if and only if 1854 that neighbor is the Designated Router or Backup Designated 1855 Router for the attached link. The LS types described in 1856 detail by this memo, namely router-LSAs (LS type 0x2001), 1857 network-LSAs (0x2002), Inter-Area-Prefix-LSAs (0x2003), 1858 Inter-Area-Router-LSAs (0x2004), AS-External-LSAs (0x4005), 1859 Link-LSAs (0x0008) and Intra-Area-Prefix-LSAs (0x2009) are 1860 assumed to be understood by all routers. However, as an 1861 example the group-membership-LSA (0x2006) is understood only 1862 by MOSPF routers and since it has its U-bit set to 0, it 1863 should only be forwarded to a non-MOSPF neighbor (determined 1864 by examining the MC-bit in the neighbor's Database 1865 Description packets' Options field) when the neighbor is 1866 Designated Router or Backup Designated Router for the 1867 attached link. 1869 The previous paragraph solves a problem in IPv4 OSPF 1870 extensions such as MOSPF, which require that the Designated 1871 Router support the extension in order to have the new LSA 1872 types flooded across broadcast and NBMA networks (see 1873 Section 10.2 of [Ref8]). 1875 3.5.3. Installing LSAs in the database 1877 There are three separate places to store LSAs, depending on 1878 their flooding scope. LSAs with AS flooding scope are stored 1879 in the global OSPF data structure (see Section 3.1) as long 1880 as their LS type is known or their U-bit is 1. LSAs with 1881 area flooding scope are stored in the appropriate area data 1882 structure (see Section 3.1.1) as long as their LS type is 1883 known or their U-bit is 1. LSAs with link-local flooding 1884 scope, and those LSAs with unknown LS type and U-bit set to 1885 0 (treat the LSA as if it had link-local flooding scope) are 1886 stored in the appropriate interface structure. 1888 When storing the LSA into the link-state database, a check 1889 must be made to see whether the LSA's contents have changed. 1890 Changes in contents are indicated exactly as in Section 13.2 1891 of [Ref1]. When an LSA's contents have been changed, the 1892 following parts of the routing table must be recalculated, 1893 based on the LSA's LS type: 1895 Router-LSAs, Network-LSAs and Intra-Area-Prefix-LSAs 1896 The entire routing table is recalculated, starting with 1897 the shortest path calculation for each area (see Section 1898 3.8). 1900 Link-LSAs 1901 The next hop of some of the routing table's entries, 1902 which is always an IPv6 link-local address, may need to 1903 be recalculated. Link-local LSAs provide the OSPF Router 1904 ID to link-local address mapping used in the next hop 1905 calculation. See Section 3.8.1.1 for details. 1907 Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs 1908 The best route to the destination described by the LSA 1909 must be recalculated (see Section 16.5 in [Ref1]). If 1910 this destination is an AS boundary router, it may also 1911 be necessary to re-examine all the AS-external-LSAs. 1913 AS-external-LSAs 1914 The best route to the destination described by the AS- 1915 external-LSA must be recalculated (see Section 16.6 in 1916 [Ref1]). 1918 As in IPv4, any old instance of the LSA must be removed from 1919 the database when the new LSA is installed. This old 1920 instance must also be removed from all neighbors' Link state 1921 retransmission lists. 1923 3.6. Definition of self-originated LSAs 1925 In IPv6 the definition of a self-originated LSA has been 1926 simplified from the IPv4 definition appearing in Sections 13.4 1927 and 14.1 of [Ref1]. For IPv6, self-originated LSAs are those 1928 LSAs whose Advertising Router is equal to the router's own 1929 Router ID. 1931 3.7. Virtual links 1933 OSPF virtual links for IPv4 are described in Section 15 of 1934 [Ref1]. Virtual links are the same in IPv6, with the following 1935 exceptions: 1937 o LSAs having AS flooding scope are never flooded over virtual 1938 adjacencies, nor are LSAs with AS flooding scope summarized 1939 over virtual adjacencies during the Database Exchange 1940 process. This is a generalization of the IPv4 treatment of 1941 AS-external-LSAs. 1943 o The IPv6 interface address of a virtual link must be an IPv6 1944 address having site-local or global scope, instead of the 1945 link-local addresses used by other interface types. This 1946 address is used as the IPv6 source for OSPF protocol packets 1947 sent over the virtual link. 1949 o Likewise, the virtual neighbor's IPv6 address is an IPv6 1950 address with site-local or global scope. To enable the 1951 discovery of a virtual neighbor's IPv6 address during the 1952 routing calculation, the neighbor advertises its virtual 1953 link's IPv6 interface address in an Intra-Area-Prefix-LSA 1954 originated for the virtual link's transit area (see Sections 1955 3.4.3.7 and 3.8.1). 1957 o Like all other IPv6 OSPF interfaces, virtual links are 1958 assigned unique (within the router) Interface IDs. These are 1959 advertised in Hellos sent over the virtual link, and in the 1960 router's router-LSAs. 1962 o IPv6 has no concept of TOS, so all discussions of TOS in 1963 Section 15 of [Ref1] are not applicable to OSPF for IPv6. 1965 3.8. Routing table calculation 1967 The IPv6 OSPF routing calculation proceeds along the same lines 1968 as the IPv4 OSPF routing calculation, following the five steps 1969 specified by Section 16 of [Ref1]. High level differences 1970 between the IPv6 and IPv4 calculations include: 1972 o Prefix information has been removed from router-LSAs, and 1973 now is advertised in intra-area-prefix-LSAs. Whenever [Ref1] 1974 specifies that stub networks within router-LSAs be examined, 1975 IPv6 will instead examine prefixes within intra-area- 1976 prefix-LSAs. 1978 o Type 3 and 4 summary-LSAs have been renamed inter-area- 1979 prefix-LSAs and inter-area-router-LSAs (respectively). 1981 o Addressing information is no longer encoded in Link State 1982 IDs, and must instead be found within the body of LSAs. 1984 o In IPv6, a router can originate multiple router-LSAs within 1985 a single area, distinguished by Link State ID. These 1986 router-LSAs must be treated as a single aggregate by the 1987 area's shortest path calculation (see Section 3.8.1). 1989 o IPv6 has no concept of TOS; all TOS routing calculations in 1990 [Ref1] are inapplicable to OSPF for IPv6. In particular, 1991 Section 16.9 of [Ref1] can be ignored for IPv6. 1993 For each area, routing table entries have been created for the 1994 area's routers and transit links, in order to store the results 1995 of the area's shortest-path tree calculation (see Section 1996 3.8.1). These entries are then used when processing intra-area- 1997 prefix-LSAs, inter-area-prefix-LSAs and inter-area-router-LSAs, 1998 as described in Section 3.8.2. 2000 Events generated as a result of routing table changes (Section 2001 16.7 of [Ref1]), and the equal-cost multipath logic (Section 2002 16.8 of [Ref1]) are identical for both IPv4 and IPv6. 2004 3.8.1. Calculating the shortest path tree for an area 2006 The IPv4 shortest path calculation is contained in Section 2007 16.1 of [Ref1]. The graph used by the shortest-path tree 2008 calculation is identical for both IPv4 and IPv6. The graph's 2009 vertices are routers and transit links, represented by 2010 router-LSAs and network-LSAs respectively. A router is 2011 identified by its OSPF Router ID, while a transit link is 2012 identified by its Designated Router's Interface ID and OSPF 2013 Router ID. Both routers and transit links have associated 2014 routing table entries within the area (see Section 3.3). 2016 Section 16.1 of [Ref1] splits up the shortest path 2017 calculations into two stages. First the Dijkstra calculation 2018 is performed, and then the stub links are added onto the 2019 tree as leaves. The IPv6 calculation maintains this split. 2021 The Dijkstra calculation for IPv6 is identical to that 2022 specified for IPv4, with the following exceptions 2023 (referencing the steps from the Dijkstra calculation as 2024 described in Section 16.1 of [Ref1]): 2026 o The Vertex ID for a router is the OSPF Router ID. The 2027 Vertex ID for a transit network is a combination of the 2028 Interface ID and OSPF Router ID of the network's 2029 Designated Router. 2031 o In Step 2, when a router Vertex V has just been added to 2032 the shortest path tree, there may be multiple LSAs 2033 associated with the router. All Router-LSAs with 2034 Advertising Router set to V's OSPF Router ID must 2035 processed as an aggregate, treating them as fragments of 2036 a single large router-LSA. The Options field and the 2037 router type bits (bits W, V, E and B) should always be 2038 taken from "fragment" with the smallest Link State ID. 2040 o Step 2a is not needed in IPv6, as there are no longer 2041 stub network links in router-LSAs. 2043 o In Step 2b, if W is a router, there may again be 2044 multiple LSAs associated with the router. All Router- 2045 LSAs with Advertising Router set to W's OSPF Router ID 2046 must processed as an aggregate, treating them as 2047 fragments of a single large router-LSA. 2049 o In Step 4, there are now per-area routing table entries 2050 for each of an area's routers, instead of just the area 2051 border routers. These entries subsume all the 2052 functionality of IPv4's area border router routing table 2053 entries, including the maintenance of virtual links. 2054 When the router added to the area routing table in this 2055 step is the other end of a virtual link, the virtual 2056 neighbor's IP address is set as follows: The collection 2057 of intra-area-prefix-LSAs originated by the virtual 2058 neighbor is examined, with the virtual neighbor's IP 2059 address being set to the first prefix encountered having 2060 the "LA-bit" set. 2062 o Routing table entries for transit networks, which are no 2063 longer associated with IP networks, are also modified in 2064 Step 4. 2066 The next stage of the shortest path calculation proceeds 2067 similarly to the two steps of the second stage of Section 2068 16.1 in [Ref1]. However, instead of examining the stub links 2069 within router-LSAs, the list of the area's intra-area- 2070 prefix-LSAs is examined. A prefix advertisement whose "NU- 2071 bit" is set should not be included in the routing 2072 calculation. The cost of any advertised prefix is the sum of 2073 the prefix' advertised metric plus the cost to the transit 2074 vertex (either router or transit network) identified by 2075 intra-area-prefix-LSA's Referenced LS type, Referenced Link 2076 State ID and Referenced Advertising Router fields. This 2077 latter cost is stored in the transit vertex' routing table 2078 entry for the area. 2080 3.8.1.1. The next hop calculation 2082 In IPv6, the calculation of the next hop's IPv6 address 2083 (which will be a link-local address) proceeds along the 2084 same lines as the IPv4 next hop calculation (see Section 2085 16.1.1 of [Ref1]). The only difference is in calculating 2086 the next hop IPv6 address for a router (call it Router 2087 X) which shares a link with the calculating router. In 2088 this case the calculating router assigns the next hop 2089 IPv6 address to be the link-local interface address 2090 contained in Router X's Link-LSA (see Section A.4.8) for 2091 the link. This procedure is necessary since on some 2092 links, such as NBMA links, the two routers need not be 2093 neighbors, and therefore might not be exchanging OSPF 2094 Hellos. 2096 3.8.2. Calculating the inter-area routes 2098 Calculation of inter-area routes for IPv6 proceeds along the 2099 same lines as the IPv4 calculation in Section 16.2 of 2100 [Ref1], with the following modifications: 2102 o The names of the Type 3 summary-LSAs and Type 4 2103 summary-LSAs have been changed to inter-area-prefix-LSAs 2104 and inter-area-router-LSAs respectively. 2106 o The Link State ID of the above LSA types no longer 2107 encodes the network or router described by the LSA. 2108 Instead, an address prefix is contained in the body of 2109 an inter-area-prefix-LSA, and a described router's OSPF 2110 Router ID is carried in the body of an inter-area- 2111 router-LSA. 2113 o Prefixes having the "NU-bit" set in their Prefix Options 2114 field should be ignored by the inter-area route 2115 calculation. 2117 When a single inter-area-prefix-LSA or inter-area-router-LSA 2118 has changed, the incremental calculations outlined in 2119 Section 16.5 of [Ref1] can be performed instead of 2120 recalculating the entire routing table. 2122 3.8.3. Examining transit areas' summary-LSAs 2124 Examination of transit areas' summary-LSAs in IPv6 proceeds 2125 along the same lines as the IPv4 calculation in Section 16.3 2126 of [Ref1], modified in the same way as the IPv6 inter-area 2127 route calculation in Section 3.8.2. 2129 3.8.4. Calculating AS external routes 2131 The IPv6 AS external route calculation proceeds along the 2132 same lines as the IPv4 calculation in Section 16.4 of 2133 [Ref1], with the following exceptions: 2135 o The Link State ID of the AS-external-LSA types no longer 2136 encodes the network described by the LSA. Instead, an 2137 address prefix is contained in the body of an AS- 2138 external-LSA. 2140 o The default route is described by AS-external-LSAs which 2141 advertise zero length prefixes. 2143 o Instead of comparing the AS-external-LSA's Forwarding 2144 address field to 0.0.0.0 to see whether a forwarding 2145 address has been used, bit F of the external-LSA is 2146 examined. A forwarding address is in use if and only if 2147 bit F is set. 2149 o Prefixes having the "NU-bit" set in their Prefix Options 2150 field should be ignored by the inter-area route 2151 calculation. 2153 When a single AS-external-LSA has changed, the incremental 2154 calculations outlined in Section 16.6 of [Ref1] can be 2155 performed instead of recalculating the entire routing table. 2157 References 2159 [Ref1] Moy, J., "OSPF Version 2", Internet Draft, , Cascade, February 1997. 2162 [Ref2] McKenzie, A., "ISO Transport Protocol specification ISO DP 2163 8073", RFC 905, ISO, April 1984. 2165 [Ref3] McCloghrie, K., and M. Rose, "Management Information Base 2166 for network management of TCP/IP-based internets: MIB-II", 2167 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 2168 International, March 1991. 2170 [Ref4] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 2171 Inter-Domain Routing (CIDR): an Address Assignment and 2172 Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, 2173 OARnet, September 1993. 2175 [Ref5] Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP--- 2176 OSPF Interaction", RFC1745, December 1994 2178 [Ref6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 2179 1700, USC/Information Sciences Institute, October 1994. 2181 [Ref7] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 2182 Over Frame Relay Networks", RFC 1586, March 1994. 2184 [Ref8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 2185 Inc., March 1994. 2187 [Ref9] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 2188 RainbowBridge Communications, Stanford University, March 2189 1994. 2191 [Ref10] Ferguson, D., "The OSPF External Attributes LSA", 2192 unpublished. 2194 [Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 2195 1793, Cascade, April 1995. 2197 [Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 2198 DECWRL, Stanford University, November 1990. 2200 [Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 2201 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco 2202 Systems, March 1995. 2204 [Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2205 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon 2206 Networks, December 1995. 2208 [Ref15] Deering, S. and R. Hinden, "IP Version 6 Addressing 2209 Architecture", RFC 1884, Xerox PARC, Ipsilon Networks, 2210 December 1995. 2212 [Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol 2213 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2214 Specification" RFC 1885, Digital Equipment Corporation, 2215 Xerox PARC, December 1995. 2217 [Ref17] Narten, T., E. Nordmark and W. Simpson, "Neighbor Discovery 2218 for IP Version 6 (IPv6)", RFC 1970, August 1996. 2220 [Ref18] McCann, J., S. Deering and J. Mogul, "Path MTU Discovery for 2221 IP version 6", RFC 1981, August 1996. 2223 [Ref19] Atkinson, R., "IP Authentication Header", RFC 1826, Naval 2224 Research Laboratory, August 1995. 2226 [Ref20] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2227 1827, Naval Research Laboratory, August 1995. 2229 A. OSPF data formats 2231 This appendix describes the format of OSPF protocol packets and OSPF 2232 LSAs. The OSPF protocol runs directly over the IPv6 network layer. 2233 Before any data formats are described, the details of the OSPF 2234 encapsulation are explained. 2236 Next the OSPF Options field is described. This field describes 2237 various capabilities that may or may not be supported by pieces of 2238 the OSPF routing domain. The OSPF Options field is contained in OSPF 2239 Hello packets, Database Description packets and in OSPF LSAs. 2241 OSPF packet formats are detailed in Section A.3. 2243 A description of OSPF LSAs appears in Section A.4. This section 2244 describes how IPv6 address prefixes are represented within LSAs, 2245 details the standard LSA header, and then provides formats for each 2246 of the specific LSA types. 2248 A.1 Encapsulation of OSPF packets 2250 OSPF runs directly over the IPv6's network layer. OSPF packets are 2251 therefore encapsulated solely by IPv6 and local data-link headers. 2253 OSPF does not define a way to fragment its protocol packets, and 2254 depends on IPv6 fragmentation when transmitting packets larger than 2255 the link MTU. If necessary, the length of OSPF packets can be up to 2256 65,535 bytes. The OSPF packet types that are likely to be large 2257 (Database Description Packets, Link State Request, Link State 2258 Update, and Link State Acknowledgment packets) can usually be split 2259 into several separate protocol packets, without loss of 2260 functionality. This is recommended; IPv6 fragmentation should be 2261 avoided whenever possible. Using this reasoning, an attempt should 2262 be made to limit the sizes of OSPF packets sent over virtual links 2263 to 576 bytes unless Path MTU Discovery is being performed. 2265 The other important features of OSPF's IPv6 encapsulation are: 2267 o Use of IPv6 multicast. Some OSPF messages are multicast, when 2268 sent over broadcast networks. Two distinct IP multicast 2269 addresses are used. Packets sent to these multicast addresses 2270 should never be forwarded; they are meant to travel a single hop 2271 only. As such, the multicast addresses have been chosen with 2272 link-local scope, and packets sent to these addresses should 2273 have their IPv6 Hop Limit set to 1. 2275 AllSPFRouters 2276 This multicast address has been assigned the value FF02::5. 2278 All routers running OSPF should be prepared to receive 2279 packets sent to this address. Hello packets are always sent 2280 to this destination. Also, certain OSPF protocol packets 2281 are sent to this address during the flooding procedure. 2283 AllDRouters 2284 This multicast address has been assigned the value FF02::6. 2285 Both the Designated Router and Backup Designated Router must 2286 be prepared to receive packets destined to this address. 2287 Certain OSPF protocol packets are sent to this address 2288 during the flooding procedure. 2290 o OSPF is IP protocol 89. This number should be inserted in the 2291 Next Header field of the encapsulating IPv6 header. 2293 o Routing protocol packets are sent with IPv6 Priority field set 2294 to 7 (internet control traffic). OSPF protocol packets should 2295 be given precedence over regular IPv6 data traffic, in both 2296 sending and receiving. 2298 A.2 The Options field 2300 The 24-bit OSPF Options field is present in OSPF Hello packets, 2301 Database Description packets and certain LSAs (router-LSAs, 2302 network-LSAs, inter-area-router-LSAs and link-LSAs). The Options 2303 field enables OSPF routers to support (or not support) optional 2304 capabilities, and to communicate their capability level to other 2305 OSPF routers. Through this mechanism routers of differing 2306 capabilities can be mixed within an OSPF routing domain. 2308 An option mismatch between routers can cause a variety of behaviors, 2309 depending on the particular option. Some option mismatches prevent 2310 neighbor relationships from forming (e.g., the E-bit below); these 2311 mismatches are discovered through the sending and receiving of Hello 2312 packets. Some option mismatches prevent particular LSA types from 2313 being flooded across adjacencies (e.g., the MC-bit below); these are 2314 discovered through the sending and receiving of Database Description 2315 packets. Some option mismatches prevent routers from being included 2316 in one or more of the various routing calculations because of their 2317 reduced functionality (again the MC-bit is an example); these 2318 mismatches are discovered by examining LSAs. 2320 Six bits of the OSPF Options field have been assigned. Each bit is 2321 described briefly below. Routers should reset (i.e. clear) 2322 unrecognized bits in the Options field when sending Hello packets or 2323 Database Description packets and when originating LSAs. Conversely, 2324 routers encountering unrecognized Option bits in received Hello 2325 Packets, Database Description packets or LSAs should ignore the 2326 capability and process the packet/LSA normally. 2328 1 2 2329 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 2331 | | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6| 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 2334 The Options field 2336 V6-bit 2337 If this bit is clear, the router/link should be excluded from 2338 IPv6 routing calculations. See Section 3.8 of this memo. 2340 E-bit 2341 This bit describes the way AS-external-LSAs are flooded, as 2342 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [Ref1]. 2344 MC-bit 2345 This bit describes whether IP multicast datagrams are forwarded 2346 according to the specifications in [Ref7]. 2348 N-bit 2349 This bit describes the handling of Type-7 LSAs, as specified in 2350 [Ref8]. 2352 R-bit 2353 This bit (the `Router' bit) indicates whether the originator is 2354 an active router. If the router bit is clear routes which 2355 transit the advertising node cannot be computed. Clearing the 2356 router bit would be appropriate for a multi-homed host that 2357 wants to participate in routing, but does not want to forward 2358 non-locally addressed packets. 2360 DC-bit 2361 This bit describes the router's handling of demand circuits, as 2362 specified in [Ref10]. 2364 A.3 OSPF Packet Formats 2366 There are five distinct OSPF packet types. All OSPF packet types 2367 begin with a standard 16 byte header. This header is described 2368 first. Each packet type is then described in a succeeding section. 2369 In these sections each packet's division into fields is displayed, 2370 and then the field definitions are enumerated. 2372 All OSPF packet types (other than the OSPF Hello packets) deal with 2373 lists of LSAs. For example, Link State Update packets implement the 2374 flooding of LSAs throughout the OSPF routing domain. The format of 2375 LSAs is described in Section A.4. 2377 The receive processing of OSPF packets is detailed in Section 3.2.2. 2378 The sending of OSPF packets is explained in Section 3.2.1. 2380 A.3.1 The OSPF packet header 2382 Every OSPF packet starts with a standard 16 byte header. Together 2383 with the encapsulating IPv6 headers, the OSPF header contains all 2384 the information necessary to determine whether the packet should be 2385 accepted for further processing. This determination is described in 2386 Section 3.2.2 of this memo. 2388 0 1 2 3 2389 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 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | Version # | Type | Packet length | 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 | Router ID | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Area ID | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | Checksum | Instance ID | 0 | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 Version # 2401 The OSPF version number. This specification documents version 3 2402 of the OSPF protocol. 2404 Type 2405 The OSPF packet types are as follows. See Sections A.3.2 through 2406 A.3.6 for details. 2408 Type Description 2409 ________________________________ 2410 1 Hello 2411 2 Database Description 2412 3 Link State Request 2413 4 Link State Update 2414 5 Link State Acknowledgment 2416 Packet length 2417 The length of the OSPF protocol packet in bytes. This length 2418 includes the standard OSPF header. 2420 Router ID 2421 The Router ID of the packet's source. 2423 Area ID 2424 A 32 bit number identifying the area that this packet belongs 2425 to. All OSPF packets are associated with a single area. Most 2426 travel a single hop only. Packets travelling over a virtual 2427 link are labelled with the backbone Area ID of 0. 2429 Checksum 2430 OSPF uses the standard checksum calculation for IPv6 2431 applications: The 16-bit one's complement of the one's 2432 complement sum of the entire contents of the packet, starting 2433 with the OSPF packet header, and prepending a "pseudo-header" of 2434 IPv6 header fields, as specified in [Ref14, section 8.1]. The 2435 Next Header value used in the pseudo-header is 89. If the 2436 packet's length is not an integral number of 16-bit words, the 2437 packet is padded with a byte of zero before checksumming. Before 2438 computing the checksum, the checksum field in the OSPF packet 2439 header is set to 0. 2441 Instance ID 2442 Enables multiple instances of OSPF to be run over a single link. 2443 Each protocol instance would be assigned a separate Instance ID; 2444 the Instance ID has local link significance only. Received 2445 packets whose Instance ID is not equal to the receiving 2446 interface's Instance ID are discarded. 2448 0 These fields are reserved. They must be 0. 2450 A.3.2 The Hello packet 2452 Hello packets are OSPF packet type 1. These packets are sent 2453 periodically on all interfaces (including virtual links) in order to 2454 establish and maintain neighbor relationships. In addition, Hello 2455 Packets are multicast on those links having a multicast or broadcast 2456 capability, enabling dynamic discovery of neighboring routers. 2458 All routers connected to a common link must agree on certain 2459 parameters (HelloInterval and RouterDeadInterval). These parameters 2460 are included in Hello packets, so that differences can inhibit the 2461 forming of neighbor relationships. The Hello packet also contains 2462 fields used in Designated Router election (Designated Router ID and 2463 Backup Designated Router ID), and fields used to detect bi- 2464 directionality (the Router IDs of all neighbors whose Hellos have 2465 been recently received). 2467 0 1 2 3 2468 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 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 | 3 | 1 | Packet length | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | Router ID | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | Area ID | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | Checksum | Instance ID | 0 | 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 | Interface ID | 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 | Rtr Pri | Options | 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | HelloInterval | RouterDeadInterval | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 | Designated Router ID | 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 | Backup Designated Router ID | 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 | Neighbor ID | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 | ... | 2492 Interface ID 2493 32-bit number uniquely identifying this interface among the 2494 collection of this router's interfaces. For example, in some 2495 implementations it may be possible to use the MIB-II IfIndex. 2497 Rtr Pri 2498 This router's Router Priority. Used in (Backup) Designated 2499 Router election. If set to 0, the router will be ineligible to 2500 become (Backup) Designated Router. 2502 Options 2503 The optional capabilities supported by the router, as documented 2504 in Section A.2. 2506 HelloInterval 2507 The number of seconds between this router's Hello packets. 2509 RouterDeadInterval 2510 The number of seconds before declaring a silent router down. 2512 Designated Router ID 2513 The identity of the Designated Router for this network, in the 2514 view of the sending router. The Designated Router is identified 2515 by its Router ID. Set to 0.0.0.0 if there is no Designated 2516 Router. 2518 Backup Designated Router ID 2519 The identity of the Backup Designated Router for this network, 2520 in the view of the sending router. The Backup Designated Router 2521 is identified by its IP Router ID. Set to 0.0.0.0 if there is 2522 no Backup Designated Router. 2524 Neighbor ID 2525 The Router IDs of each router from whom valid Hello packets have 2526 been seen recently on the network. Recently means in the last 2527 RouterDeadInterval seconds. 2529 A.3.3 The Database Description packet 2531 Database Description packets are OSPF packet type 2. These packets 2532 are exchanged when an adjacency is being initialized. They describe 2533 the contents of the link-state database. Multiple packets may be 2534 used to describe the database. For this purpose a poll-response 2535 procedure is used. One of the routers is designated to be the 2536 master, the other the slave. The master sends Database Description 2537 packets (polls) which are acknowledged by Database Description 2538 packets sent by the slave (responses). The responses are linked to 2539 the polls via the packets' DD sequence numbers. 2541 0 1 2 3 2542 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 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 | 3 | 2 | Packet length | 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 | Router ID | 2547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2548 | Area ID | 2549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 | Checksum | Instance ID | 0 | 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 | 0 | Options | 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | Interface MTU | 0 |0|0|0|0|0|I|M|MS 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | DD sequence number | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | | 2559 +- -+ 2560 | | 2561 +- An LSA Header -+ 2562 | | 2563 +- -+ 2564 | | 2565 +- -+ 2566 | | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | ... | 2570 The format of the Database Description packet is very similar to 2571 both the Link State Request and Link State Acknowledgment packets. 2572 The main part of all three is a list of items, each item describing 2573 a piece of the link-state database. The sending of Database 2574 Description Packets is documented in Section 10.8 of [Ref1]. The 2575 reception of Database Description packets is documented in Section 2576 10.6 of [Ref1]. 2578 Options 2579 The optional capabilities supported by the router, as documented 2580 in Section A.2. 2582 Interface MTU 2583 The size in bytes of the largest IPv6 datagram that can be sent 2584 out the associated interface, without fragmentation. The MTUs 2585 of common Internet link types can be found in Table 7-1 of 2586 [Ref12]. Interface MTU should be set to 0 in Database 2587 Description packets sent over virtual links. 2589 I-bit 2590 The Init bit. When set to 1, this packet is the first in the 2591 sequence of Database Description Packets. 2593 M-bit 2594 The More bit. When set to 1, it indicates that more Database 2595 Description Packets are to follow. 2597 MS-bit 2598 The Master/Slave bit. When set to 1, it indicates that the 2599 router is the master during the Database Exchange process. 2600 Otherwise, the router is the slave. 2602 DD sequence number 2603 Used to sequence the collection of Database Description Packets. 2604 The initial value (indicated by the Init bit being set) should 2605 be unique. The DD sequence number then increments until the 2606 complete database description has been sent. 2608 The rest of the packet consists of a (possibly partial) list of the 2609 link-state database's pieces. Each LSA in the database is described 2610 by its LSA header. The LSA header is documented in Section A.4.1. 2611 It contains all the information required to uniquely identify both 2612 the LSA and the LSA's current instance. 2614 A.3.4 The Link State Request packet 2616 Link State Request packets are OSPF packet type 3. After exchanging 2617 Database Description packets with a neighboring router, a router may 2618 find that parts of its link-state database are out-of-date. The 2619 Link State Request packet is used to request the pieces of the 2620 neighbor's database that are more up-to-date. Multiple Link State 2621 Request packets may need to be used. 2623 A router that sends a Link State Request packet has in mind the 2624 precise instance of the database pieces it is requesting. Each 2625 instance is defined by its LS sequence number, LS checksum, and LS 2626 age, although these fields are not specified in the Link State 2627 Request Packet itself. The router may receive even more recent 2628 instances in response. 2630 The sending of Link State Request packets is documented in Section 2631 10.9 of [Ref1]. The reception of Link State Request packets is 2632 documented in Section 10.7 of [Ref1]. 2634 0 1 2 3 2635 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 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | 3 | 3 | Packet length | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2639 | Router ID | 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | Area ID | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | Checksum | Instance ID | 0 | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | 0 | LS type | 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 | Link State ID | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 | Advertising Router | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 | ... | 2653 Each LSA requested is specified by its LS type, Link State ID, and 2654 Advertising Router. This uniquely identifies the LSA, but not its 2655 instance. Link State Request packets are understood to be requests 2656 for the most recent instance (whatever that might be). 2658 A.3.5 The Link State Update packet 2660 Link State Update packets are OSPF packet type 4. These packets 2661 implement the flooding of LSAs. Each Link State Update packet 2662 carries a collection of LSAs one hop further from their origin. 2663 Several LSAs may be included in a single packet. 2665 Link State Update packets are multicast on those physical networks 2666 that support multicast/broadcast. In order to make the flooding 2667 procedure reliable, flooded LSAs are acknowledged in Link State 2668 Acknowledgment packets. If retransmission of certain LSAs is 2669 necessary, the retransmitted LSAs are always carried by unicast Link 2670 State Update packets. For more information on the reliable flooding 2671 of LSAs, consult Section 3.5. 2673 0 1 2 3 2674 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 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 | 3 | 4 | Packet length | 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 | Router ID | 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | Area ID | 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 | Checksum | Instance ID | 0 | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 | # LSAs | 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 | | 2687 +- +-+ 2688 | LSAs | 2689 +- +-+ 2690 | ... | 2692 # LSAs 2693 The number of LSAs included in this update. 2695 The body of the Link State Update packet consists of a list of LSAs. 2696 Each LSA begins with a common 20 byte header, described in Section 2697 A.4.2. Detailed formats of the different types of LSAs are described 2698 in Section A.4. 2700 A.3.6 The Link State Acknowledgment packet 2702 Link State Acknowledgment Packets are OSPF packet type 5. To make 2703 the flooding of LSAs reliable, flooded LSAs are explicitly 2704 acknowledged. This acknowledgment is accomplished through the 2705 sending and receiving of Link State Acknowledgment packets. The 2706 sending of Link State Acknowledgement packets is documented in 2707 Section 13.5 of [Ref1]. The reception of Link State Acknowledgement 2708 packets is documented in Section 13.7 of [Ref1]. 2710 Multiple LSAs can be acknowledged in a single Link State 2711 Acknowledgment packet. Depending on the state of the sending 2712 interface and the sender of the corresponding Link State Update 2713 packet, a Link State Acknowledgment packet is sent either to the 2714 multicast address AllSPFRouters, to the multicast address 2715 AllDRouters, or as a unicast (see Section 13.5 of [Ref1] for 2716 details). 2718 The format of this packet is similar to that of the Data Description 2719 packet. The body of both packets is simply a list of LSA headers. 2721 0 1 2 3 2722 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 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | 3 | 5 | Packet length | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | Router ID | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 | Area ID | 2729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 | Checksum | Instance ID | 0 | 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 | | 2733 +- -+ 2734 | | 2735 +- An LSA Header -+ 2736 | | 2737 +- -+ 2738 | | 2739 +- -+ 2740 | | 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2742 | ... | 2744 Each acknowledged LSA is described by its LSA header. The LSA 2745 header is documented in Section A.4.2. It contains all the 2746 information required to uniquely identify both the LSA and the LSA's 2747 current instance. 2749 A.4 LSA formats 2751 This memo defines seven distinct types of LSAs. Each LSA begins 2752 with a standard 20 byte LSA header. This header is explained in 2753 Section A.4.2. Succeeding sections then diagram the separate LSA 2754 types. 2756 Each LSA describes a piece of the OSPF routing domain. Every router 2757 originates a router-LSA. A network-LSA is advertised for each link 2758 by its Designated Router. A router's link-local addresses are 2759 advertised to its neighbors in link-LSAs. IPv6 prefixes are 2760 advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs and 2761 AS-external-LSAs. Location of specific routers can be advertised 2762 across area boundaries in inter-area-router-LSAs. All LSAs are then 2763 flooded throughout the OSPF routing domain. The flooding algorithm 2764 is reliable, ensuring that all routers have the same collection of 2765 LSAs. (See Section 3.5 for more information concerning the flooding 2766 algorithm). This collection of LSAs is called the link-state 2767 database. 2769 From the link state database, each router constructs a shortest path 2770 tree with itself as root. This yields a routing table (see Section 2771 11 of [Ref1]). For the details of the routing table build process, 2772 see Section 3.8. 2774 A.4.1 IPv6 Prefix Representation 2776 IPv6 addresses are bit strings of length 128. IPv6 routing 2777 algorithms, and OSPF for IPv6 in particular, advertise IPv6 address 2778 prefixes. IPv6 address prefixes are bit strings whose length ranges 2779 between 0 and 128 bits (inclusive). 2781 Within OSPF, IPv6 address prefixes are always represented by a 2782 combination of three fields: PrefixLength, PrefixOptions, and 2783 Address Prefix. PrefixLength is the length in bits of the prefix. 2784 PrefixOptions is an 8-bit field describing various capabilities 2785 associated with the prefix (see Section A.4.2). Address Prefix is an 2786 encoding of the prefix itself as an even multiple of 32-bit words, 2787 padding with zero bits as necessary; this encoding consumes 2788 (PrefixLength + 31) / 32) 32-bit words. 2790 The default route is represented by a prefix of length 0. 2792 Examples of IPv6 Prefix representation in OSPF can be found in 2793 Sections A.4.5, A.4.7, A.4.8 and A.4.9. 2795 A.4.1.1 Prefix Options 2797 Each prefix is advertised along with an 8-bit field of capabilities. 2798 These serve as input to the various routing calculations, allowing, 2799 for example, certain prefixes to be ignored in some cases, or to be 2800 marked as not readvertisable in others. 2802 0 1 2 3 4 5 6 7 2803 +--+--+--+--+--+--+--+--+ 2804 | | | | | P|MC|LA|NU| 2805 +--+--+--+--+--+--+--+--+ 2807 The Prefix Options field 2809 NU-bit 2810 The "no unicast" capability bit. If set, the prefix should be 2811 excluded from IPv6 unicast calculations, otherwise it should be 2812 included. 2814 LA-bit 2815 The "local address" capability bit. If set, the prefix is 2816 actually an IPv6 interface address of the advertising router. 2818 MC-bit 2819 The "multicast" capability bit. If set, the prefix should be 2820 included in IPv6 multicast routing calculations, otherwise it 2821 should be excluded. 2823 P-bit 2824 The "propagate" bit. Set on NSSA area prefixes that should be 2825 readvertised at the NSSA area border. 2827 A.4.2 The LSA header 2829 All LSAs begin with a common 20 byte header. This header contains 2830 enough information to uniquely identify the LSA (LS type, Link State 2831 ID, and Advertising Router). Multiple instances of the LSA may 2832 exist in the routing domain at the same time. It is then necessary 2833 to determine which instance is more recent. This is accomplished by 2834 examining the LS age, LS sequence number and LS checksum fields that 2835 are also contained in the LSA header. 2837 0 1 2 3 2838 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 2839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2840 | LS age | LS type | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 | Link State ID | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 | Advertising Router | 2845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 | LS sequence number | 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2848 | LS checksum | length | 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 LS age 2852 The time in seconds since the LSA was originated. 2854 LS type 2855 The LS type field indicates the function performed by the LSA. 2856 The high-order three bits of LS type encode generic properties 2857 of the LSA, while the remainder (called LSA function code) 2858 indicate the LSA's specific functionality. See Section A.4.2.1 2859 for a detailed description of LS type. 2861 Link State ID 2862 Together with LS type and Advertising Router, uniquely 2863 identifies the LSA in the link-state database. 2865 Advertising Router 2866 The Router ID of the router that originated the LSA. For 2867 example, in network-LSAs this field is equal to the Router ID of 2868 the network's Designated Router. 2870 LS sequence number 2871 Detects old or duplicate LSAs. Successive instances of an LSA 2872 are given successive LS sequence numbers. See Section 12.1.6 in 2873 [Ref1] for more details. 2875 LS checksum 2876 The Fletcher checksum of the complete contents of the LSA, 2877 including the LSA header but excluding the LS age field. See 2878 Section 12.1.7 in [Ref1] for more details. 2880 length 2881 The length in bytes of the LSA. This includes the 20 byte LSA 2882 header. 2884 A.4.2.1 LS type 2886 The LS type field indicates the function performed by the LSA. The 2887 high-order three bits of LS type encode generic properties of the 2888 LSA, while the remainder (called LSA function code) indicate the 2889 LSA's specific functionality. The format of the LS type is as 2890 follows: 2892 1 2893 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2894 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2895 |U |S2|S1| LSA Function Code | 2896 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2898 The U bit indicates how the LSA should be handled by a router which 2899 does not recognize the LSA's function code. Its values are: 2901 U-bit LSA Handling 2902 ____________________________________________________________ 2903 0 Treat the LSA as if it had link-local flooding scope 2904 1 Store and flood the LSA, as if type understood 2906 The S1 and S2 bits indicate the flooding scope of the LSA. The 2907 values are: 2909 S2 S1 Flooding Scope 2910 _______________________________________________________________________ 2911 0 0 Link-Local Scoping. Flooded only on link it is originated on. 2912 0 1 Area Scoping. Flooded to all routers in the originating area 2913 1 0 AS Scoping. Flooded to all routers in the AS 2914 1 1 Reserved 2916 The LSA function codes are defined as follows. The origination and 2917 processing of these LSA function codes are defined elsewhere in this 2918 memo, except for the group-membership-LSA (see [Ref7]) and the 2919 Type-7-LSA (see [Ref8]). Each LSA function code also implies a 2920 specific setting for the U, S1 and S2 bits, as shown below. 2922 LSA function code LS Type Description 2923 ___________________________________________________ 2924 1 0x2001 Router-LSA 2925 2 0x2002 Network-LSA 2926 3 0x2003 Inter-Area-Prefix-LSA 2927 4 0x2004 Inter-Area-Router-LSA 2928 5 0x4005 AS-External-LSA 2929 6 0x2006 Group-membership-LSA 2930 7 0x2007 Type-7-LSA 2931 8 0x0008 Link-LSA 2932 9 0x2009 Intra-Area-Prefix-LSA 2933 A.4.3 Router-LSAs 2935 Router-LSAs have LS type equal to 0x2001. Each router in an area 2936 originates one or more router-LSAs. The complete collection of 2937 router-LSAs originated by the router describe the state and cost of 2938 the router's interfaces to the area. For details concerning the 2939 construction of router-LSAs, see Section 3.4.3.1. Router-LSAs are 2940 flooded throughout a single area only. 2942 0 1 2 3 2943 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 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 | LS age |0|0|1| 1 | 2946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2947 | Link State ID | 2948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 | Advertising Router | 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 | LS sequence number | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2953 | LS checksum | length | 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 | 0 |W|V|E|B| Options | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 | Type | 0 | Metric | 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2959 | Interface ID | 2960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2961 | Neighbor Interface ID | 2962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2963 | Neighbor Router ID | 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | ... | 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2967 | Type | 0 | Metric | 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 | Interface ID | 2970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 | Neighbor Interface ID | 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2973 | Neighbor Router ID | 2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2975 | ... | 2977 A single router may originate one or more Router LSAs, distinguished 2978 by their Link-State IDs (which are chosen arbitrarily by the 2979 originating router). The Options field and V, E and B bits should 2980 be the same in all Router LSAs from a single originator. However, 2981 in the case of a mismatch the values in the LSA with the lowest Link 2982 State ID take precedence. When more than one Router LSA is received 2983 from a single router, the links are processed as if concatenated 2984 into a single LSA. 2986 bit V 2987 When set, the router is an endpoint of one or more fully 2988 adjacent virtual links having the described area as Transit area 2989 (V is for virtual link endpoint). 2991 bit E 2992 When set, the router is an AS boundary router (E is for 2993 external). 2995 bit B 2996 When set, the router is an area border router (B is for border). 2998 bit W 2999 When set, the router is a wild-card multicast receiver. When 3000 running MOSPF, these routers receive all multicast datagrams, 3001 regardless of destination. See Sections 3, 4 and A.2 of [Ref8] 3002 for details. 3004 Options 3005 The optional capabilities supported by the router, as documented 3006 in Section A.2. 3008 The following fields are used to describe each router interface. 3009 The Type field indicates the kind of interface being described. It 3010 may be an interface to a transit network, a point-to-point 3011 connection to another router or a virtual link. The values of all 3012 the other fields describing a router interface depend on the 3013 interface's Type field. 3015 Type 3016 The kind of interface being described. One of the following: 3018 Type Description 3019 __________________________________________________ 3020 1 Point-to-point connection to another router 3021 2 Connection to a transit network 3022 3 Reserved 3023 4 Virtual link 3025 Metric 3026 The cost of using this router interface, for outbound traffic. 3028 Interface ID 3029 The Interface ID assigned to the interface being described. See 3030 Sections 3.1.2 and C.3. 3032 Neighbor Interface ID 3033 The Interface ID the neighbor router (or the attached link's 3034 Designated Router, for Type 2 interfaces) has been advertising 3035 in hello packets sent on the attached link. 3037 Neighbor Router ID 3038 The Router ID the neighbor router (or the attached link's 3039 Designated Router, for Type 2 interfaces). 3041 For Type 2 links, the combination of Neighbor Interface ID and 3042 Neighbor Router ID allows the network-LSA for the attached link 3043 to be found in the link-state database. 3045 A.4.4 Network-LSAs 3047 Network-LSAs have LS type equal to 0x2002. A network-LSA is 3048 originated for each broadcast and NBMA link in the area which 3049 supports two or more routers. The network-LSA is originated by the 3050 link's Designated Router. The LSA describes all routers attached to 3051 the link, including the Designated Router itself. The LSA's Link 3052 State ID field is set to the Interface ID that the Designated Router 3053 has been advertising in Hello packets on the link. 3055 The distance from the network to all attached routers is zero. This 3056 is why the metric fields need not be specified in the network-LSA. 3057 For details concerning the construction of network-LSAs, see Section 3058 3.4.3.2. 3060 0 1 2 3 3061 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 3062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3063 | LS age |0|0|1| 2 | 3064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 | Link State ID | 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3067 | Advertising Router | 3068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3069 | LS sequence number | 3070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3071 | LS checksum | length | 3072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3073 | 0 | Options | 3074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 | Attached Router | 3076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 | ... | 3079 Attached Router 3080 The Router IDs of each of the routers attached to the link. 3081 Actually, only those routers that are fully adjacent to the 3082 Designated Router are listed. The Designated Router includes 3083 itself in this list. The number of routers included can be 3084 deduced from the LSA header's length field. 3086 A.4.5 Inter-Area-Prefix-LSAs 3088 Inter-Area-Prefix-LSAs have LS type equal to 0x2003. These LSAs are 3089 are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see 3090 Section 12.4.3 of [Ref1]). Originated by area border routers, they 3091 describe routes to IPv6 address prefixes that belong to other areas. 3092 A separate Inter-Area-Prefix-LSA is originated for each IPv6 address 3093 prefix. For details concerning the construction of Inter-Area- 3094 Prefix-LSAs, see Section 3.4.3.3. 3096 For stub areas, Inter-Area-Prefix-LSAs can also be used to describe 3097 a (per-area) default route. Default summary routes are used in stub 3098 areas instead of flooding a complete set of external routes. When 3099 describing a default summary route, the Inter-Area-Prefix-LSA's 3100 PrefixLength is set to 0. 3102 0 1 2 3 3103 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 3104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3105 | LS age |0|0|1| 3 | 3106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3107 | Link State ID | 3108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3109 | Advertising Router | 3110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3111 | LS sequence number | 3112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3113 | LS checksum | length | 3114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3115 | 0 | Metric | 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3117 | PrefixLength | PrefixOptions | (0) | 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 | Address Prefix | 3120 | ... | 3121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3123 Metric 3124 The cost of this route. Expressed in the same units as the 3125 interface costs in the router-LSAs. When the Inter-Area-Prefix- 3126 LSA is describing a route to a range of addresses (see Section 3127 C.2) the cost is set to the maximum cost to any reachable 3128 component of the address range. 3130 PrefixLength, PrefixOptions and Address Prefix 3131 Representation of the IPv6 address prefix, as described in 3132 Section A.4.1. 3134 A.4.6 Inter-Area-Router-LSAs 3136 Inter-Area-Router-LSAs have LS type equal to 0x2004. These LSAs are 3137 are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see 3138 Section 12.4.3 of [Ref1]). Originated by area border routers, they 3139 describe routes to routers in other areas. (To see why it is 3140 necessary to advertise the location of each ASBR, consult Section 3141 16.4 in [Ref1].) Each LSA describes a route to a single router. For 3142 details concerning the construction of Inter-Area-Router-LSAs, see 3143 Section 3.4.3.4. 3145 0 1 2 3 3146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3148 | LS age |0|0|1| 4 | 3149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3150 | Link State ID | 3151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3152 | Advertising Router | 3153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3154 | LS sequence number | 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 | LS checksum | length | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | 0 | Options | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 | 0 | Metric | 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3162 | Destination Router ID | 3163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3165 Options 3166 The optional capabilities supported by the router, as documented 3167 in Section A.2. 3169 Metric 3170 The cost of this route. Expressed in the same units as the 3171 interface costs in the router-LSAs. 3173 Destination Router ID 3174 The Router ID of the router being described by the LSA. 3176 A.4.7 AS-external-LSAs 3178 AS-external-LSAs have LS type equal to 0x4005. These LSAs are 3179 originated by AS boundary routers, and describe destinations 3180 external to the AS. Each LSA describes a route to a single IPv6 3181 address prefix. For details concerning the construction of AS- 3182 external-LSAs, see Section 3.4.3.5. 3184 AS-external-LSAs can be used to describe a default route. Default 3185 routes are used when no specific route exists to the destination. 3186 When describing a default route, the AS-external-LSA's PrefixLength 3187 is set to 0. 3189 0 1 2 3 3190 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 3191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3192 | LS age |0|1|0| 5 | 3193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3194 | Link State ID | 3195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3196 | Advertising Router | 3197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3198 | LS sequence number | 3199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3200 | LS checksum | length | 3201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3202 | |E|F|T| Metric | 3203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3204 | PrefixLength | PrefixOptions | Referenced LS Type | 3205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3206 | Address Prefix | 3207 | ... | 3208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3209 | | 3210 +- -+ 3211 | | 3212 +- Forwarding Address (Optional) -+ 3213 | | 3214 +- -+ 3215 | | 3216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3217 | External Route Tag (Optional) | 3218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 | Referenced Link State ID (Optional) | 3220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3222 bit E 3223 The type of external metric. If bit E is set, the metric 3224 specified is a Type 2 external metric. This means the metric is 3225 considered larger than any intra-AS path. If bit E is zero, the 3226 specified metric is a Type 1 external metric. This means that 3227 it is expressed in the same units as the link state metric 3228 (i.e., the same units as interface cost). 3230 bit F 3231 If set, a Forwarding Address has been included in the LSA. 3233 bit T 3234 If set, an External Route Tag has been included in the LSA. 3236 Metric 3237 The cost of this route. Interpretation depends on the external 3238 type indication (bit E above). 3240 PrefixLength, PrefixOptions and Address Prefix 3241 Representation of the IPv6 address prefix, as described in 3242 Section A.4.1. 3244 Referenced LS type 3245 If non-zero, an LSA with this LS type is to be associated with 3246 this LSA (see Referenced Link State ID below). 3248 Forwarding address 3249 A fully qualified IPv6 address (128 bits). Included in the LSA 3250 if and only if bit F has been set. If included, Data traffic 3251 for the advertised destination and TOS will be forwarded to this 3252 address. Must not be set to the IPv6 Unspecified Address 3253 (0:0:0:0:0:0:0:0). 3255 External Route Tag 3256 A 32-bit field which may be used to communicate additional 3257 information between AS boundary routers; see [Ref5] for example 3258 usage. Included in the LSA if and only if bit T has been set. 3260 Referenced Link State ID 3261 Included if and only if Reference LS Type is non-zero. If 3262 included, additional information concerning the advertised 3263 external route can be found in the LSA having LS type equal to 3264 "Referenced LS Type", Link State ID equal to "Referenced Link 3265 State ID" and Advertising Router the same as that specified in 3266 the AS-external-LSA's link state header. This additional 3267 information is not used by the OSPF protocol itself. It may be 3268 used to communicate information between AS boundary routers; the 3269 precise nature of such information is outside the scope of this 3270 specification. 3272 All, none or some of the fields labeled Forwarding address, External 3273 Route Tag and Referenced Link State ID may be present in the AS- 3274 external-LSA (as indicated by the setting of bit F, bit T and 3275 Referenced LS type respectively). However, when present Forwarding 3276 Address always comes first, with External Route Tag always preceding 3277 Referenced Link State ID. 3279 A.4.8 Link-LSAs 3281 Link-LSAs have LS type equal to 0x0008. A router originates a 3282 separate Link-LSA for each link it is attached to. These LSAs have 3283 local-link flooding scope; they are never flooded beyond the link 3284 that they are associated with. Link-LSAs have three purposes: 1) 3285 they provide the router's link-local address to all other routers 3286 attached to the link and 2) they inform other routers attached to 3287 the link of a list of IPv6 prefixes to associate with the link and 3288 3) they allow the router to assert a collection of Options bits to 3289 associate with the Network-LSA that will be originated for the link. 3291 A link-LSA's Link State ID is set equal to the originating router's 3292 Interface ID on the link. 3293 0 1 2 3 3294 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 3295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3296 | LS age |0|0|0| 8 | 3297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3298 | Link State ID | 3299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3300 | Advertising Router | 3301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3302 | LS sequence number | 3303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3304 | LS checksum | length | 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 | Rtr Pri | Options | 3307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3308 | | 3309 +- -+ 3310 | | 3311 +- Link-local Interface Address -+ 3312 | | 3313 +- -+ 3314 | | 3315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3316 | # prefixes | 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 | PrefixLength | PrefixOptions | (0) | 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 | Address Prefix | 3321 | ... | 3322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3323 | ... | 3324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3325 | PrefixLength | PrefixOptions | (0) | 3326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3327 | Address Prefix | 3328 | ... | 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 Rtr Pri 3332 The Router Priority of the interface attaching the originating 3333 router to the link. 3335 Options 3336 The set of Options bits that the router would like set in the 3337 Network-LSA that will be originated for the link. 3339 Link-local Interface Address 3340 The originating router's link-local interface address on the 3341 link. 3343 # prefixes 3344 The number of IPv6 address prefixes contained in the LSA. 3346 The rest of the link-LSA contains a list of IPv6 prefixes to be 3347 associated with the link. 3349 PrefixLength, PrefixOptions and Address Prefix 3350 Representation of an IPv6 address prefix, as described in 3351 Section A.4.1. 3353 A.4.9 Intra-Area-Prefix-LSAs 3355 Intra-Area-Prefix-LSAs have LS type equal to 0x2009. A router uses 3356 Intra-Area-Prefix-LSAs to advertise one or more IPv6 address 3357 prefixes that are associated with a) the router itself, b) an 3358 attached stub network segment or c) an attached transit network 3359 segment. In IPv4, a) and b) were accomplished via the router's 3360 router-LSA, and c) via a network-LSA. However, in OSPF for IPv6 all 3361 addressing information has been removed from router-LSAs and 3362 network-LSAs, leading to the introduction of the Intra-Area-Prefix- 3363 LSA. 3365 A router can originate multiple Intra-Area-Prefix-LSAs for each 3366 router or transit network; each such LSA is distinguished by its 3367 Link State ID. 3369 0 1 2 3 3370 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 3371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3372 | LS age |0|0|1| 9 | 3373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3374 | Link State ID | 3375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3376 | Advertising Router | 3377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3378 | LS sequence number | 3379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3380 | LS checksum | length | 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3382 | # prefixes | Referenced LS type | 3383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3384 | Referenced Link State ID | 3385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3386 | Referenced Advertising Router | 3387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3388 | PrefixLength | PrefixOptions | Metric | 3389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3390 | Address Prefix | 3391 | ... | 3392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 | ... | 3394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3395 | PrefixLength | PrefixOptions | Metric | 3396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 | Address Prefix | 3398 | ... | 3399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3401 # prefixes 3402 The number of IPv6 address prefixes contained in the LSA. 3404 Referenced LS type, Referenced Link State ID and Referenced 3405 Advertising Router 3406 Identifies the router-LSA or network-LSA with which the IPv6 3407 address prefixes should be associated. If Referenced LS type is 3408 1, the prefixes are associated with a router-LSA, Referenced 3409 Link State ID should be 0 and Referenced Advertising Router 3410 should be the originating router's Router ID. If Referenced LS 3411 type is 2, the prefixes are associated with a network-LSA, 3412 Referenced Link State ID should be the Interface ID of the 3413 link's Designated Router and Referenced Advertising Router 3414 should be the Designated Router's Router ID. 3416 The rest of the Intra-Area-Prefix-LSA contains a list of IPv6 3417 prefixes to be associated with the router or transit link, together 3418 with the cost of each prefix. 3420 PrefixLength, PrefixOptions and Address Prefix 3421 Representation of an IPv6 address prefix, as described in 3422 Section A.4.1. 3424 Metric 3425 The cost of this prefix. Expressed in the same units as the 3426 interface costs in the router-LSAs. 3428 B. Architectural Constants 3430 Architectural constants for the OSPF protocol are defined in 3431 Appendix C of [Ref1]. The only difference for OSPF for IPv6 is that 3432 DefaultDestination is encoded as a prefix of length 0 (see Section 3433 A.4.1). 3435 C. Configurable Constants 3437 The OSPF protocol has quite a few configurable parameters. These 3438 parameters are listed below. They are grouped into general 3439 functional categories (area parameters, interface parameters, etc.). 3440 Sample values are given for some of the parameters. 3442 Some parameter settings need to be consistent among groups of 3443 routers. For example, all routers in an area must agree on that 3444 area's parameters, and all routers attached to a network must agree 3445 on that network's HelloInterval and RouterDeadInterval. 3447 Some parameters may be determined by router algorithms outside of 3448 this specification (e.g., the address of a host connected to the 3449 router via a SLIP line). From OSPF's point of view, these items are 3450 still configurable. 3452 C.1 Global parameters 3454 In general, a separate copy of the OSPF protocol is run for each 3455 area. Because of this, most configuration parameters are 3456 defined on a per-area basis. The few global configuration 3457 parameters are listed below. 3459 Router ID 3460 This is a 32-bit number that uniquely identifies the router 3461 in the Autonomous System. If a router's OSPF Router ID is 3462 changed, the router's OSPF software should be restarted 3463 before the new Router ID takes effect. Before restarting in 3464 order to change its Router ID, the router should flush its 3465 self-originated LSAs from the routing domain (see Section 3466 14.1 of [Ref1]), or they will persist for up to MaxAge 3467 minutes. 3469 Because the size of the Router ID is smaller than an IPv6 3470 address, it cannot be set to one of the router's IPv6 3471 addresses (as is commonly done for IPv4). Possible Router ID 3472 assignment procedures for IPv6 include: a) assign the IPv6 3473 Router ID as one of the router's IPv4 addresses or b) assign 3474 IPv6 Router IDs through some local administrative procedure 3475 (similar to procedures used by manufacturers to assign 3476 product serial numbers). 3478 The Router ID of 0.0.0.0 is reserved, and should not be 3479 used. 3481 C.2 Area parameters 3483 All routers belonging to an area must agree on that area's 3484 configuration. Disagreements between two routers will lead to 3485 an inability for adjacencies to form between them, with a 3486 resulting hindrance to the flow of routing protocol and data 3487 traffic. The following items must be configured for an area: 3489 Area ID 3490 This is a 32-bit number that identifies the area. The Area 3491 ID of 0 is reserved for the backbone. 3493 List of address ranges 3494 Address ranges control the advertisement of routes across 3495 area boundaries. Each address range consists of the 3496 following items: 3498 [IPv6 prefix, prefix length] 3499 Describes the collection of IPv6 addresses contained 3500 in the address range. 3502 Status Set to either Advertise or DoNotAdvertise. Routing 3503 information is condensed at area boundaries. 3504 External to the area, at most a single route is 3505 advertised (via a inter-area-prefix-LSA) for each 3506 address range. The route is advertised if and only 3507 if the address range's Status is set to Advertise. 3508 Unadvertised ranges allow the existence of certain 3509 networks to be intentionally hidden from other 3510 areas. Status is set to Advertise by default. 3512 ExternalRoutingCapability 3513 Whether AS-external-LSAs will be flooded into/throughout the 3514 area. If AS-external-LSAs are excluded from the area, the 3515 area is called a "stub". Internal to stub areas, routing to 3516 external destinations will be based solely on a default 3517 inter-area route. The backbone cannot be configured as a 3518 stub area. Also, virtual links cannot be configured through 3519 stub areas. For more information, see Section 3.6 of 3520 [Ref1]. 3522 StubDefaultCost 3523 If the area has been configured as a stub area, and the 3524 router itself is an area border router, then the 3525 StubDefaultCost indicates the cost of the default inter- 3526 area-prefix-LSA that the router should advertise into the 3527 area. See Section 12.4.3.1 of [Ref1] for more information. 3529 C.3 Router interface parameters 3531 Some of the configurable router interface parameters (such as 3532 Area ID, HelloInterval and RouterDeadInterval) actually imply 3533 properties of the attached links, and therefore must be 3534 consistent across all the routers attached to that link. The 3535 parameters that must be configured for a router interface are: 3537 IPv6 link-local address 3538 The IPv6 link-local address associated with this interface. 3539 May be learned through auto-configuration. 3541 Area ID 3542 The OSPF area to which the attached link belongs. 3544 Instance ID 3545 The OSPF protocol instance associated with this OSPF 3546 interface. Defaults to 0. 3548 Interface ID 3549 32-bit number uniquely identifying this interface among the 3550 collection of this router's interfaces. For example, in some 3551 implementations it may be possible to use the MIB-II 3552 IfIndex. 3554 IPv6 prefixes 3555 The list of IPv6 prefixes to associate with the link. These 3556 will be advertised in intra-area-prefix-LSAs. 3558 Interface output cost(s) 3559 The cost of sending a packet on the interface, expressed in 3560 the link state metric. This is advertised as the link cost 3561 for this interface in the router's router-LSA. The interface 3562 output cost must always be greater than 0. 3564 RxmtInterval 3565 The number of seconds between LSA retransmissions, for 3566 adjacencies belonging to this interface. Also used when 3567 retransmitting Database Description and Link State Request 3568 Packets. This should be well over the expected round-trip 3569 delay between any two routers on the attached link. The 3570 setting of this value should be conservative or needless 3571 retransmissions will result. Sample value for a local area 3572 network: 5 seconds. 3574 InfTransDelay 3575 The estimated number of seconds it takes to transmit a Link 3576 State Update Packet over this interface. LSAs contained in 3577 the update packet must have their age incremented by this 3578 amount before transmission. This value should take into 3579 account the transmission and propagation delays of the 3580 interface. It must be greater than 0. Sample value for a 3581 local area network: 1 second. 3583 Router Priority 3584 An 8-bit unsigned integer. When two routers attached to a 3585 network both attempt to become Designated Router, the one 3586 with the highest Router Priority takes precedence. If there 3587 is still a tie, the router with the highest Router ID takes 3588 precedence. A router whose Router Priority is set to 0 is 3589 ineligible to become Designated Router on the attached link. 3590 Router Priority is only configured for interfaces to 3591 broadcast and NBMA networks. 3593 HelloInterval 3594 The length of time, in seconds, between the Hello Packets 3595 that the router sends on the interface. This value is 3596 advertised in the router's Hello Packets. It must be the 3597 same for all routers attached to a common link. The smaller 3598 the HelloInterval, the faster topological changes will be 3599 detected; however, more OSPF routing protocol traffic will 3600 ensue. Sample value for a X.25 PDN: 30 seconds. Sample 3601 value for a local area network (LAN): 10 seconds. 3603 RouterDeadInterval 3604 After ceasing to hear a router's Hello Packets, the number 3605 of seconds before its neighbors declare the router down. 3606 This is also advertised in the router's Hello Packets in 3607 their RouterDeadInterval field. This should be some 3608 multiple of the HelloInterval (say 4). This value again 3609 must be the same for all routers attached to a common link. 3611 C.4 Virtual link parameters 3613 Virtual links are used to restore/increase connectivity of the 3614 backbone. Virtual links may be configured between any pair of 3615 area border routers having interfaces to a common (non-backbone) 3616 area. The virtual link appears as an unnumbered point-to-point 3617 link in the graph for the backbone. The virtual link must be 3618 configured in both of the area border routers. 3620 A virtual link appears in router-LSAs (for the backbone) as if 3621 it were a separate router interface to the backbone. As such, 3622 it has most of the parameters associated with a router interface 3623 (see Section C.3). Virtual links do not have link-local 3624 addresses, but instead use one of the router's global-scope or 3625 site-local IPv6 addresses as the IP source in OSPF protocol 3626 packets it sends along the virtual link. Router Priority is not 3627 used on virtual links. Interface output cost is not configured 3628 on virtual links, but is dynamically set to be the cost of the 3629 intra-area path between the two endpoint routers. The parameter 3630 RxmtInterval must be configured, and should be well over the 3631 expected round-trip delay between the two routers. This may be 3632 hard to estimate for a virtual link; it is better to err on the 3633 side of making it too large. 3635 A virtual link is defined by the following two configurable 3636 parameters: the Router ID of the virtual link's other endpoint, 3637 and the (non-backbone) area through which the virtual link runs 3638 (referred to as the virtual link's Transit area). Virtual links 3639 cannot be configured through stub areas. 3641 C.5 NBMA network parameters 3643 OSPF treats an NBMA network much like it treats a broadcast 3644 network. Since there may be many routers attached to the 3645 network, a Designated Router is selected for the network. This 3646 Designated Router then originates a network-LSA, which lists all 3647 routers attached to the NBMA network. 3649 However, due to the lack of broadcast capabilities, it may be 3650 necessary to use configuration parameters in the Designated 3651 Router selection. These parameters will only need to be 3652 configured in those routers that are themselves eligible to 3653 become Designated Router (i.e., those router's whose Router 3654 Priority for the network is non-zero), and then only if no 3655 automatic procedure for discovering neighbors exists: 3657 List of all other attached routers 3658 The list of all other routers attached to the NBMA network. 3659 Each router is configured with its Router ID and IPv6 link- 3660 local address on the network. Also, for each router listed, 3661 that router's eligibility to become Designated Router must 3662 be defined. When an interface to a NBMA network comes up, 3663 the router sends Hello Packets only to those neighbors 3664 eligible to become Designated Router, until the identity of 3665 the Designated Router is discovered. 3667 PollInterval 3668 If a neighboring router has become inactive (Hello Packets 3669 have not been seen for RouterDeadInterval seconds), it may 3670 still be necessary to send Hello Packets to the dead 3671 neighbor. These Hello Packets will be sent at the reduced 3672 rate PollInterval, which should be much larger than 3673 HelloInterval. Sample value for a PDN X.25 network: 2 3674 minutes. 3676 C.6 Point-to-MultiPoint network parameters 3678 On Point-to-MultiPoint networks, it may be necessary to 3679 configure the set of neighbors that are directly reachable over 3680 the Point-to-MultiPoint network. Each neighbor is configured 3681 with its Router ID and IPv6 link-local address on the network. 3682 Designated Routers are not elected on Point-to-MultiPoint 3683 networks, so the Designated Router eligibility of configured 3684 neighbors is undefined. 3686 C.7 Host route parameters 3688 Host routes are advertised in intra-area-prefix-LSAs as fully 3689 qualified IPv6 prefixes (i.e., prefix length set equal to 128 3690 bits). They indicate either router interfaces to point-to-point 3691 networks, looped router interfaces, or IPv6 hosts that are 3692 directly connected to the router (e.g., via a PPP connection). 3693 For each host directly connected to the router, the following 3694 items must be configured: 3696 Host IPv6 address 3697 The IPv6 address of the host. 3699 Cost of link to host 3700 The cost of sending a packet to the host, in terms of the 3701 link state metric. However, since the host probably has only 3702 a single connection to the internet, the actual configured 3703 cost(s) in many cases is unimportant (i.e., will have no 3704 effect on routing). 3706 Area ID 3707 The OSPF area to which the host belongs. 3709 Security Considerations 3711 When running over IPv6, OSPF relies on the IP Authentication Header 3712 (see [Ref19]) and the IP Encapsulating Security Payload (see 3713 [Ref20]) to ensure integrity and authentication/confidentiality of 3714 routing exchanges. 3716 Authors Addresses 3718 Rob Coltun 3719 FORE Systems 3720 Phone: (301) 571-2521 3721 Email: rcoltun@fore.com 3723 Dennis Ferguson 3724 Juniper Networks 3725 101 University Avenue, Suite 240 3726 Palo Alto, CA 94301 3727 Phone: (415) 614-4143 3728 Email: dennis@jnx.com 3730 John Moy 3731 Cascade Communications Corp. 3732 5 Carlisle Road 3733 Westford, MA 01886 3734 Phone: (508) 952-1367 3735 Fax: (508) 392-9250 3736 Email: jmoy@casc.com 3738 This document expires in September 1997.