idnits 2.17.1 draft-ietf-ospf-ospfv6-01.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-25) 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 1206 instances of lines with control characters in the document. 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 (February 1996) is 10297 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 410, but no explicit reference was found in the text == Unused Reference: 'Ref3' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'Ref4' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'Ref6' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'Ref9' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'Ref11' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'Ref12' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'Ref13' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'Ref15' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'Ref16' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'Ref17' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'Ref18' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'Ref120' is defined on line 1896, 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref17' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref18' ** Obsolete normative reference: RFC 1826 (ref. 'Ref19') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. 'Ref20') (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref120' Summary: 23 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Coltun 2 Internet Draft FORE Systems 3 Expiration Date: August 1996 D. Ferguson 4 File name: draft-ietf-ospf-ospfv6-01.txt Ipsilon Networks 5 Network Working Group J. Moy 6 Internet Draft Cascade Communications Corp. 7 February 1996 9 OSPF for IPv6 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This document describes the modifications to OSPF to support version 32 6 of the Internet Protocol (IPv6). The fundamental mechanisms of 33 OSPF (flooding, DR election, area support, SPF calculations, etc.) 34 remain unchanged. However, some changes have been necessary, either 35 due to changes in protocol semantics between IPv4 and IPv6, or 36 simply to handle the increased address size of IPv6. 38 Changes between OSPF for IPv4 and this document include the 39 following. Addressing semantics have been removed from OSPF packets 40 and the basic LSAs. New LSAs have been created to carry IPv6 41 addresses and prefixes. OSPF now runs a a per-link basis, instead of 42 on a per-IP-subnet basis. Flooding scope for LSAs has been 43 generalized. Authentication has been removed from the OSPF protocol 44 itself, instead relying on IPv6's Authentication Header and 45 Encapsulating Security Payload. 47 Most packets in OSPF for IPv6 are almost as compact as those in OSPF 48 for IPv4l, even with the larger IPv6 addresses. Most field- and 49 packet-size limitations present in OSPF for IPv4 have been relaxed. 50 In addition, option handling has been made more flexible. 52 All of OSPF for IPv4's optional capabilities, including on-demand 53 circuit support, NSSA areas, and the multicast extensions to OSPF 54 (MOSPF) are also supported in OSPF for IPv6. 56 Please send comments to ospf@gated.cornell.edu. 58 Table of Contents 60 1 Introduction ........................................... 5 61 1.1 Terminology ............................................ 5 62 2 Differences from OSPF for IPv4 ......................... 5 63 2.1 Protocol processing per-link, not per-subnet ........... 5 64 2.2 Removal of addressing semantics ........................ 6 65 2.3 Addition of Flooding scope ............................. 6 66 2.4 Explicit support for multiple instances per link ....... 7 67 2.5 Use of link-local addresses ............................ 7 68 2.6 Authentication changes ................................. 7 69 2.7 Packet format changes .................................. 8 70 2.8 LSA format changes ..................................... 8 71 2.9 Handling unknown LSA types ............................ 10 72 2.10 Removal of TOS ........................................ 10 73 3 Implementation details ................................ 11 74 References ............................................ 12 75 A OSPF data formats ..................................... 14 76 A.1 Encapsulation of OSPF packets ......................... 14 77 A.2 The Options field ..................................... 16 78 A.3 OSPF Packet Formats ................................... 18 79 A.3.1 The OSPF packet header ................................ 19 80 A.3.2 The Hello packet ...................................... 21 81 A.3.3 The Database Description packet ....................... 23 82 A.3.4 The Link State Request packet ......................... 25 83 A.3.5 The Link State Update packet .......................... 26 84 A.3.6 The Link State Acknowledgment packet .................. 27 85 A.4 LSA formats ........................................... 28 86 A.4.1 IPv6 Prefix Representation ............................ 30 87 A.4.1.1 Prefix Options ........................................ 31 88 A.4.2 The LSA header ........................................ 32 89 A.4.2.1 LS type ............................................... 34 90 A.4.3 Router-LSAs ........................................... 36 91 A.4.4 Network-LSAs .......................................... 39 92 A.4.5 Inter-Area-Prefix-LSAs ................................ 40 93 A.4.6 Inter-Area-Router-LSAs ................................ 41 94 A.4.7 AS-external-LSAs ...................................... 42 95 A.4.8 Link-LSAs ............................................. 44 96 A.4.9 Intra-Area-Prefix-LSAs ................................ 46 97 B Architectural Constants ............................... 48 98 C Configurable Constants ................................ 48 99 C.1 Global parameters ..................................... 48 100 C.2 Area parameters ....................................... 48 101 C.3 Router interface parameters ........................... 49 102 C.4 Virtual link parameters ............................... 51 103 C.5 NBMA network parameters ............................... 52 104 C.6 Point-to-MultiPoint network parameters ................ 53 105 C.7 Host route parameters ................................. 53 107 Security Considerations ............................... 54 108 Authors' Addresses .................................... 54 109 1. Introduction 111 This document describes the modifications to OSPF to support version 112 6 of the Internet Protocol (IPv6). The fundamental mechanisms of 113 OSPF (flooding, DR election, area support, SPF calculations, etc.) 114 remain unchanged. However, some changes have been necessary, either 115 due to changes in protocol semantics between IPv4 and IPv6, or 116 simply to handle the increased address size of IPv6. 118 This document is organized as follows. Section 2 describes the 119 differences betweed OSPF for IPv4 and OSPF for IPv6 in detail. 120 Section 3 provides implementation details for the changes. Appendix 121 A gives the OSPF for IPv6 packet and LSA formats. Appendix B lists 122 the OSPF architectural constants. Appendix C describes configuration 123 parameters. 125 1.1. Terminology 127 This document attempts to use terms from both the OSPF for IPv4 128 specification ([Ref1]) and the IPv6 protocol specifications 129 ([Ref14]). This has produced a mixed result. Most of the terms 130 used both by OSPF and IPv6 have roughly the same meaning (e.g., 131 interfaces). However, there are a few conflicts. IPv6 uses 132 "link" similarly to IPv4 OSPF's "subnet" or "network". In this 133 case, we have chosen to use IPv6's "link" terminology. "Link" 134 replaces OSPF's "subnet" and "network" in most places in this 135 document, although OSPF's Network-LSA remains unchanged (and 136 possibly unfortunately, a new Link-LSA has also been created). 138 The names of some of the OSPF LSAs have also changed. See 139 Section 2.8 for details. 141 2. Differences from OSPF for IPv4 143 Most of the algorithms from OSPF for IPv4 [Ref1] have preserved in 144 OSPF for IPv6. However, some changes have been necessary, either due 145 to changes in protocol semantics between IPv4 and IPv6, or simply to 146 handle the increased address size of IPv6. 148 The following subsections describe the differences between this 149 document and [Ref1]. 151 2.1. Protocol processing per-link, not per-subnet 153 IPv6 uses the term "link" to indicate "a communication facility 154 or medium over which nodes can communicate at the link layer" 155 ([Ref14]). "Interfaces" connect to links. Multiple IP subnets 156 can be assigned to a single link, and two nodes can talk 157 directly over a single link, even if they do not share a common 158 IP subnet (IPv6 prefix). 160 For this reason, OSPF for IPv6 runs per-link instead of the IPv4 161 behavior of per-IP-subnet. The terms "network" and "subnet" used 162 in the IPv4 OSPF specification ([Ref1]) should generally be 163 relaced by link. Likewise, an OSPF interface now connects to a 164 link instead of and IP subnet, etc. 166 This change affects the receiving of OSPF protocol packets, and 167 the contents of Hello Packets and Network-LSAs. 169 2.2. Removal of addressing semantics 171 In OSPF for IPv6, addressing semantics have been removed from 172 the OSPF protocol packets and the main LSA types, leaving a 173 network-protocol-independent core. In particular: 175 o IPv6 Addresses are not present in OSPF packets, except for 176 in LSA payloads carried by the Link State Update Packets. 177 See Section 2.7 for details. 179 o Router-LSAs and Network-LSAs no longer contain network 180 addresses, but simply express topology information. See 181 Section 2.8 for details. 183 o OSPF Router IDs, Area IDs and LSA Link State IDs remain at 184 the IPv4 size of 32-bits. They can no longer be assigned as 185 (IPv6) addresses. 187 o Neighboring routers are now always identified by Router ID, 188 where previously they had been identified by IP address on 189 broadcast and NBMA "networks". 191 2.3. Addition of Flooding scope 193 Flooding scope for LSAs has been generalized and is now 194 explicitly coded in the LSA's LS type field. There are now three 195 separate flooding scopes for LSAs: 197 o Link-local scope. LSA is flooded only on the local link, and 198 no further. Used for the new Link-LSA (see Section A.4.8). 200 o Area scope. LSA is flooded throughout a single OSPF area 201 only. Used for Router-LSAs, Network-LSAs, Inter-Area- 202 Prefix-LSAs, Inter-Area-Router-LSAs and Intra-Area-Prefix- 203 LSAs. 205 o AS scope. LSA is flooded throughout the routing domain. Used 206 for AS-external-LSAs. 208 2.4. Explicit support for multiple instances per link 210 OSPF now supports the ability to run multiple OSPF protocol 211 instances on a single link. For example, this may be required on 212 a NAP segment shared between several providers -- providers may 213 be running a separate OSPF routing domains that want to remain 214 separate even though they have one or more physical network 215 segments (i.e., links) in common. In OSPF for IPv4 this was 216 supported in a haphazard fashion using the authentication fields 217 in the OSPF for IPv4 header. 219 Another use for running multiple OSPF instances is if you want, 220 for one reason or another, to have a single link belog to two or 221 more OSPF areas. 223 Support for multiple protocol instances on a link is 224 accomplished via an "Instance ID" contained in the OSPF packet 225 header and OSPF interface structures. Instance ID solely affects 226 the reception of OSPF packets. 228 2.5. Use of link-local addresses 230 On all interfaces except virtual links, OSPF packets are sent 231 using the link-local interface address as source. A router 232 learns the link-local interface addresses of all other routers 233 attached to its links, and uses these addresses as next hop 234 information for packet forwarding. 236 On virtual links, global scope or site-local IP addresses must 237 be used as the source for OSPF protocol packets. 239 2.6. Authentication changes 241 In OSPF for IPv6, authentication has been removed from OSPF 242 itself. The "Autype" and "Authentication" fields have been 243 removed from the OSPF packet header, and all authentication 244 related fields have been removed from the OSPF area and 245 interface structures. 247 When running over IPv6, OSPF relies on the IP Authentication 248 Header (see [Ref19]) and the IP Encapsulating Security Payload 249 (see [Ref20]) to ensure integrity and 250 authentication/confidentiality of routing exchanges. 252 2.7. Packet format changes 254 OSPF for IPv6 runs directly over IPv6. Aside from this, all 255 addressing semantics have been removed from the OSPF packet 256 headers, making it essentially "network-protocol independent". 257 All addressing information is now contain in various LSA types 258 only. 260 In detail, changes in OSPF packet format consist of the 261 following: 263 o The OSPF version number has been increased from 2 to 3. 265 o The Options field in Hello Packets and Database description 266 Packets has been expanded to 24-bits. 268 o The Authentication and AuType fields have been removed from 269 the OSPF packet header (see Section 2.6). 271 o The Hello packet now contains no address information at all, 272 and includes a Interface ID which the originating router has 273 assigned to uniquely identify (among its own interfaces) its 274 interface to the link. This Interface ID becomes the 275 Network-LSA's Link State ID, should the router become 276 Designated Router on the link. 278 o Two options bits have been added to the Options field for 279 processing Router-LSAs during the SPF calculation (see 280 Section A.2). The "V6-bit" allows routers to participate in 281 OSPF topology distribution, but avoid the forwarding of IPv6 282 datagrams. The "R-bit" allows nodes to participate in OSPF 283 topology distribution, but avoid being used to forward 284 transit traffic. This latter option could be used in multi- 285 homed hosts that want to participate in routing 286 calculations. 288 o The OSPF packet header now includes an "Instance ID" which 289 allows multiple OSPF protocol instances to be run on a 290 single link (see Section 2.4). 292 2.8. LSA format changes 294 All addressing semantics have been removed from the LSA header, 295 and from Router-LSAs and Network-LSAs. These two LSAs now 296 describe the routing domain's topology in a network-protocol 297 independent manner. New LSAs have been added to distribute IPv6 298 address information, and data required for next hop resolution. 299 The names of some of IPv4's LSAs have been changed to be more 300 consistent with each other. 302 In detail, changes in LSA format consist of the following: 304 o The Options field has been removed from the LSA header, 305 expanded to 24 bits, and moved into the body of Router-LSAs, 306 Network-LSAs, Inter-Area-Router-LSAs and Link-LSAs. 308 o The LSA Type field has been expanded (into the former 309 Options space) to 16 bits, with the upper three bits 310 encoding flooding scope and the handling of unknow LSA types 311 (see Section 2.9). 313 o Addresses in LSAs are now expresses as [prefix, prefix 314 length] instead of [address, mask] (see Section A.4.1). The 315 default route is expressed as a prefix with length 0. 317 o The Router and Network LSAs now have no address information, 318 and are network-protocol-independent. 320 o Router interface information may be spread across multiple 321 Router LSAs. Receivers must concatenate all the Router-LSAs 322 originated by a given router when running the SPF 323 calculation. 325 o A new LSA called the Link-LSA has been introduced. The LSAs 326 have local-link flooding scope; they are never flooded 327 beyond the link that they are associated with. Link-LSAs 328 have three purposes: 1) they provide the router's link-local 329 address to all other routers attached to the link and 2) 330 they inform other routers attached to the link of a list of 331 IPv6 prefixes to associate with the link and 3) they allow 332 the router to assert a collection of Options bits to 333 associate with the Network-LSA that will be originated for 334 the link. See Section A.4.8 for details. 336 o The Options field in the Network LSA is set to the logical 337 OR of the Options that each router on the link advertises in 338 its Link-LSA. 340 o Type-3 summary-LSAs have been renamed "Inter-Area-Prefix- 341 LSAs". Type-4 summary LSAs have been renamed "Inter-Area- 342 Router-LSAs". 344 o The Link State ID in Inter-Area-Prefix-LSAs, Inter-Area- 345 Router-LSAs and AS-external-LSAs has lost its addressing 346 semantics, and now serves solely to identify individual 347 pieces of the Link State Database. All addresses or Router 348 IDs that formerly were expressed by the Link State ID are 349 now carried in the LSA bodies. 351 o Network-LSAs and Link-LSAs are the only LSAs whose Link 352 State ID carries additional meaning. For these LSAs, the 353 Link State ID is always the Interface ID of the originating 354 router on the link being described. For this reason, 355 Network-LSAs and Link-LSAs are now the only LSAs that cannot 356 be broken into arbitrarily small pieces. 358 o A new LSA called the Inter-Area-Prefix-LSA has been 359 introduced. This LSA carries all IPv6 prefix information 360 that in IPv4 is included in Router-LSAs and Network-LSAs. 361 See Section A.4.6 for details. 363 o Inclusion of a forwarding address in AS-external-LSAs is now 364 optional. In addition, AS-external-LSAs can now reference 365 another LSA, for inclusion of route attributes outside the 366 scope of the OSPF protocol itself. For example, this can be 367 used to attach tags to OSPF external routes as in [Ref5], or 368 BGP path attributes as proposed in [Ref10]. 370 2.9. Handling unknown LSA types 372 Handling of unknown LSA types has been made more flexible so 373 that, based on LS type, unknown LSA types are either treated as 374 having link-local flooding scope, or are stored and flooded as 375 if they were understood (desirable for things like the proposed 376 External Attributes LSA in [Ref10]). This behavior is explicitly 377 coded in the LSA Handling bit of the link state header's LS type 378 field (see Section A.4.2.1). 380 The IPv4 OSPF behavior of simply discarding unknown types is 381 unsupported due to the desire to mix router capabilities on a 382 single link. Discarding unknown types causes problems when the 383 Designated Router supports fewer options than the other routers 384 on the link. 386 2.10. Removal of TOS 388 The semantics of IPv4 TOS have not been moved forward to IPv6. 389 Therfore, support for TOS in OSPF for IPv6 has been removed. 390 This affects both LSA formats and routing calculations. 392 The IPv6 header does have a 24-bit Flow Label field which may be 393 used by a source to label those packets for which it requests 394 special handling by IPv6 routers, such as non-default quality of 395 service or "real-time" ser- vice. The OSPF LSAs for IPv6 have 396 been organized so that future extensions to support routing 397 based on Flow Label are possible. 399 3. Implementation details 401 To be written. Strategy will be to refer to IPv4 as much as 402 possible. Only when changes are major is a section completely 403 rewritten. 405 References 407 [Ref1] Moy, J., "OSPF Version 2", Internet Draft, , Cascade, November 1995. 410 [Ref2] McKenzie, A., "ISO Transport Protocol specification ISO DP 411 8073", RFC 905, ISO, April 1984. 413 [Ref3] McCloghrie, K., and M. Rose, "Management Information Base 414 for network management of TCP/IP-based internets: MIB-II", 415 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 416 International, March 1991. 418 [Ref4] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 419 Inter-Domain Routing (CIDR): an Address Assignment and 420 Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, 421 OARnet, September 1993. 423 [Ref5] Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP--- 424 OSPF Interaction", RFC1745, December 1994 426 [Ref6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 427 1700, USC/Information Sciences Institute, October 1994. 429 [Ref7] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 430 Over Frame Relay Networks", RFC 1586, March 1994. 432 [Ref8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 433 Inc., March 1994. 435 [Ref9] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 436 RainbowBridge Communications, Stanford University, March 437 1994. 439 [Ref10] Ferguson, D., "The OSPF External Attributes LSA", 440 unpublished. 442 [Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 443 1793, Cascade, April 1995. 445 [Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 446 DECWRL, Stanford University, November 1990. 448 [Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 449 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco 450 Systems, March 1995. 452 [Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6 453 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon 454 Networks, December 1995. 456 [Ref15] Deering, S. and R. Hinden, "IP Version 6 Addressing 457 Architecture", RFC 1884, Xerox PARC, Ipsilon Networks, 458 December 1995. 460 [Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol 461 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 462 Specification" RFC 1885, Digital Equipment Corporation, 463 Xerox PARC, December 1995. 465 [Ref17] Narten, T., E. Nordmark and W. A. Simpson, "Neighbor 466 Discovery for IP Version 6 (IPv6)", IBM, Sun Microsystems, 467 work in progress. 469 [Ref18] McCann, J. and S. Deering, "Path MTU Discovery for IP 470 version 6", Digital Equipment Corporation, Xerox PARC, work 471 in progress. 473 [Ref19] Atkinson, R., "IP Authentication Header", RFC 1826, Naval 474 Research Laboratory, August 1995. 476 [Ref20] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 477 1827, Naval Research Laboratory, August 1995. 479 A. OSPF data formats 481 This appendix describes the format of OSPF protocol packets and OSPF 482 LSAs. The OSPF protocol runs directly over the IPv6 network layer. 483 Before any data formats are described, the details of the OSPF 484 encapsulation are explained. 486 Next the OSPF Options field is described. This field describes 487 various capabilities that may or may not be supported by pieces of 488 the OSPF routing domain. The OSPF Options field is contained in OSPF 489 Hello packets, Database Description packets and in OSPF LSAs. 491 OSPF packet formats are detailed in Section A.3. 493 A description of OSPF LSAs appears in Section A.4. This section 494 describes how IPv6 address prefixes are represented within LSAs, 495 details the standard LSA header, and then provides formats for each 496 of the specific LSA types. 498 A.1 Encapsulation of OSPF packets 500 OSPF runs directly over the IPv6's network layer. OSPF packets are 501 therefore encapsulated solely by IPv6 and local data-link headers. 503 OSPF does not define a way to fragment its protocol packets, and 504 depends on IPv6 fragmentation when transmitting packets larger than 505 the link MTU. If necessary, the length of OSPF packets can be up to 506 65,535 bytes. The OSPF packet types that are likely to be large 507 (Database Description Packets, Link State Request, Link State 508 Update, and Link State Acknowledgment packets) can usually be split 509 into several separate protocol packets, without loss of 510 functionality. This is recommended; IPv6 fragmentation should be 511 avoided whenever possible. Using this reasoning, an attempt should 512 be made to limit the sizes of OSPF packets sent over virtual links 513 to 576 bytes unless Path MTU Discovery is being performed. 515 The other important features of OSPF's IPv6 encapsulation are: 517 o Use of IPv6 multicast. Some OSPF messages are multicast, when 518 sent over broadcast networks. Two distinct IP multicast 519 addresses are used. Packets sent to these multicast addresses 520 should never be forwarded; they are meant to travel a single hop 521 only. As such, the multicast addresses have been chosen with 522 link-local scope, and packets sent to these addresses should 523 have their IPv6 Hop Limit set to 1. 525 AllSPFRouters 526 This multicast address has been assigned the value FF02::5. 528 All routers running OSPF should be prepared to receive 529 packets sent to this address. Hello packets are always sent 530 to this destination. Also, certain OSPF protocol packets 531 are sent to this address during the flooding procedure. 533 AllDRouters 534 This multicast address has been assigned the value FF02::6. 535 Both the Designated Router and Backup Designated Router must 536 be prepared to receive packets destined to this address. 537 Certain OSPF protocol packets are sent to this address 538 during the flooding procedure. 540 o OSPF is IP protocol 89. This number should be inserted in the 541 Next Header field of the enapsulating IPv6 header. 543 o Routing protocol packets are sent with IPv6 Priority field set 544 to 7 (internet control traffic). OSPF protocol packets should 545 be given precedence over regular IPv6 data traffic, in both 546 sending and receiving. 548 A.2 The Options field 550 The 24-bit OSPF Options field is present in OSPF Hello packets, 551 Database Description packets and certain LSAs (router-LSAs, 552 network-LSAs, inter-area-router-LSAs and link-LSAs). The Options 553 field enables OSPF routers to support (or not support) optional 554 capabilities, and to communicate their capability level to other 555 OSPF routers. Through this mechanism routers of differing 556 capabilities can be mixed within an OSPF routing domain. 558 When used in Hello packets, the Options field allows a router to 559 reject a neighbor because of a capability mismatch. Alternatively, 560 when capabilities are exchanged in Database Description packets a 561 router can choose not to forward certain LSAs to a neighbor because 562 of its reduced functionality. Lastly, listing capabilities in LSAs 563 allows routers to forward data traffic around reduced functionality 564 routers, by excluding them from parts of the routing table 565 calculation. 567 Six bits of the OSPF Options field have been assigned. Each bit is 568 described briefly below. Routers should reset (i.e. clear) 569 unrecognized bits in the Options field when sending Hello packets or 570 Database Description packets and when originating LSAs. Conversely, 571 routers encountering unrecognized Option bits in received Hello 572 Packets, Database Description packets or LSAs should ignore the 573 capability and process the packet/LSA normally. 575 1 2 576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 578 | | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6| 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 581 The Options field 583 V6-bit 584 The bit indicates whether the router/link should be included in 585 IPv6 routing calculations. See Section XXXX of this memo. 587 E-bit 588 This bit describes the way AS-external-LSAs are flooded, as 589 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [Ref1]. 591 MC-bit 592 This bit describes whether IP multicast datagrams are forwarded 593 according to the specifications in [Ref7]. 595 N-bit 596 This bit describes the handling of Type-7 LSAs, as specified in 597 [Ref8]. 599 R-bit 600 This bit (the `Router' bit) indicates whether the originator is 601 an active router. If the router bit is clear routes which 602 transit the advertising node may not be computed. Clearing the 603 router bit would be appropriate for a multi-homed host that 604 wants to participate in routing, but does not want to forward 605 non-locally addressed packets. See Section XXXX of this memo. 607 DC-bit 608 This bit describes the router's handling of demand circuits, as 609 specified in [Ref10]. 611 A.3 OSPF Packet Formats 613 There are five distinct OSPF packet types. All OSPF packet types 614 begin with a standard 20 byte header. This header is described 615 first. Each packet type is then described in a succeeding section. 616 In these sections each packet's division into fields is displayed, 617 and then the field definitions are enumerated. 619 All OSPF packet types (other than the OSPF Hello packets) deal with 620 lists of LSAs. For example, Link State Update packets implement the 621 flooding of LSAs throughout the OSPF routing domain. The format of 622 LSAs is described in Section A.4. 624 The receive processing of OSPF packets is detailed in Section XXXX. 625 The sending of OSPF packets is explained in Section XXXX. 627 A.3.1 The OSPF packet header 629 Every OSPF packet starts with a standard 20 byte header. Together 630 with the encapsulating IPv6 headers, the OSPF header contains all 631 the information necessary to determine whether the packet should be 632 accepted for further processing. This determination is described in 633 Section XXXX of this memo. 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Version # | Type | Packet length | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Router ID | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Area ID | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Checksum | Instance ID | 0 | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Version # 648 The OSPF version number. This specification documents version 3 649 of the OSPF protocol. 651 Type 652 The OSPF packet types are as follows. See Sections A.3.2 through 653 A.3.6 for details. 655 Type Description 656 ________________________________ 657 1 Hello 658 2 Database Description 659 3 Link State Request 660 4 Link State Update 661 5 Link State Acknowledgment 663 Packet length 664 The length of the OSPF protocol packet in bytes. This length 665 includes the standard OSPF header. 667 Router ID 668 The Router ID of the packet's source. 670 Area ID 671 A 32 bit number identifying the area that this packet belongs 672 to. All OSPF packets are associated with a single area. Most 673 travel a single hop only. Packets travelling over a virtual 674 link are labelled with the backbone Area ID of 0. 676 Checksum 677 The standard IP checksum of the entire contents of the packet, 678 starting with the OSPF packet header. This checksum is 679 calculated as the 16-bit one's complement of the one's 680 complement sum of all the 16-bit words in the packet. If the 681 packet's length is not an integral number of 16-bit words, the 682 packet is padded with a byte of zero before checksumming. 684 Instance ID 685 Enables multiple instances of OSPF to be run over a single link. 686 Each protocol instance would be assigned a separate Instance ID; 687 the Instance ID has local link significance only. Received 688 packets whose Instance ID is not equal to the receiving 689 interface's Instance ID are discarded. 691 0 These fields are reserved. They must be 0. 693 A.3.2 The Hello packet 695 Hello packets are OSPF packet type 1. These packets are sent 696 periodically on all interfaces (including virtual links) in order to 697 establish and maintain neighbor relationships. In addition, Hello 698 Packets are multicast on those links having a multicast or broadcast 699 capability, enabling dynamic discovery of neighboring routers. 701 All routers connected to a common link must agree on certain 702 parameters (HelloInterval and RouterDeadInterval). These parameters 703 are included in Hello packets, so that differences can inhibit the 704 forming of neighbor relationships. The Hello packet also contains 705 fields used in Designated Router election (Designated Router ID and 706 Backup Designated Router ID), and fields used to detect bi- 707 directionality (the Router IDs of all neighbors whose Hellos have 708 been recently received). 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Version # | 1 | Packet length | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Router ID | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Area ID | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Checksum | Instance ID | 0 | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Interface ID | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Rtr Pri | Options | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | HelloInterval | RouterDeadInterval | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Designated Router ID | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Backup Designated Router ID | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Neighbor ID | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | ... | 735 Interface ID 736 32-bit number uniquely identifying this interface among the 737 collection of this router's interfaces. For example, in some 738 implementations it may be possible to use the MIB-II IfIndex. 740 Rtr Pri 741 This router's Router Priority. Used in (Backup) Designated 742 Router election. If set to 0, the router will be ineligible to 743 become (Backup) Designated Router. 745 Options 746 The optional capabilities supported by the router, as documented 747 in Section A.2. 749 HelloInterval 750 The number of seconds between this router's Hello packets. 752 RouterDeadInterval 753 The number of seconds before declaring a silent router down. 755 Designated Router ID 756 The identity of the Designated Router for this network, in the 757 view of the sending router. The Designated Router is identified 758 by its Router ID. Set to 0.0.0.0 if there is no Designated 759 Router. 761 Backup Designated Router ID 762 The identity of the Backup Designated Router for this network, 763 in the view of the sending router. The Backup Designated Router 764 is identified by its IP Router ID. Set to 0.0.0.0 if there is 765 no Backup Designated Router. 767 Neighbor ID 768 The Router IDs of each router from whom valid Hello packets have 769 been seen recently on the network. Recently means in the last 770 RouterDeadInterval seconds. 772 A.3.3 The Database Description packet 774 Database Description packets are OSPF packet type 2. These packets 775 are exchanged when an adjacency is being initialized. They describe 776 the contents of the link-state database. Multiple packets may be 777 used to describe the database. For this purpose a poll-response 778 procedure is used. One of the routers is designated to be the 779 master, the other the slave. The master sends Database Description 780 packets (polls) which are acknowledged by Database Description 781 packets sent by the slave (responses). The responses are linked to 782 the polls via the packets' DD sequence numbers. 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Version # | 2 | Packet length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Router ID | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Area ID | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Checksum | Instance ID | 0 | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 |0|0|0|0|0|I|M|MS Options | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | DD sequence number | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | | 800 +- -+ 801 | | 802 +- An LSA Header -+ 803 | | 804 +- -+ 805 | | 806 +- -+ 807 | | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | ... | 811 The format of the Database Description packet is very similar to 812 both the Link State Request and Link State Acknowledgment packets. 813 The main part of all three is a list of items, each item describing 814 a piece of the link-state database. The sending of Database 815 Description Packets is documented in Section 10.8 of [Ref1]. The 816 reception of Database Description packets is documented in Section 817 10.6 of [Ref1]. 819 I-bit 820 The Init bit. When set to 1, this packet is the first in the 821 sequence of Database Description Packets. 823 M-bit 824 The More bit. When set to 1, it indicates that more Database 825 Description Packets are to follow. 827 MS-bit 828 The Master/Slave bit. When set to 1, it indicates that the 829 router is the master during the Database Exchange process. 830 Otherwise, the router is the slave. 832 Options 833 The optional capabilities supported by the router, as documented 834 in Section A.2. 836 DD sequence number 837 Used to sequence the collection of Database Description Packets. 838 The initial value (indicated by the Init bit being set) should 839 be unique. The DD sequence number then increments until the 840 complete database description has been sent. 842 The rest of the packet consists of a (possibly partial) list of the 843 link-state database's pieces. Each LSA in the database is described 844 by its LSA header. The LSA header is documented in Section A.4.1. 845 It contains all the information required to uniquely identify both 846 the LSA and the LSA's current instance. 848 A.3.4 The Link State Request packet 850 Link State Request packets are OSPF packet type 3. After exchanging 851 Database Description packets with a neighboring router, a router may 852 find that parts of its link-state database are out-of-date. The 853 Link State Request packet is used to request the pieces of the 854 neighbor's database that are more up-to-date. Multiple Link State 855 Request packets may need to be used. 857 A router that sends a Link State Request packet has in mind the 858 precise instance of the database pieces it is requesting. Each 859 instance is defined by its LS sequence number, LS checksum, and LS 860 age, although these fields are not specified in the Link State 861 Request Packet itself. The router may receive even more recent 862 instances in response. 864 The sending of Link State Request packets is documented in Section 865 10.9 of [Ref1]. The reception of Link State Request packets is 866 documented in Section 10.7 of [Ref1]. 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Version # | 3 | Packet length | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Router ID | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Area ID | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Checksum | Instance ID | 0 | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | 0 | LS type | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Link State ID | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Advertising Router | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | ... | 887 Each LSA requested is specified by its LS type, Link State ID, and 888 Advertising Router. This uniquely identifies the LSA, but not its 889 instance. Link State Request packets are understood to be requests 890 for the most recent instance (whatever that might be). 892 A.3.5 The Link State Update packet 894 Link State Update packets are OSPF packet type 4. These packets 895 implement the flooding of LSAs. Each Link State Update packet 896 carries a collection of LSAs one hop further from their origin. 897 Several LSAs may be included in a single packet. 899 Link State Update packets are multicast on those physical networks 900 that support multicast/broadcast. In order to make the flooding 901 procedure reliable, flooded LSAs are acknowledged in Link State 902 Acknowledgment packets. If retransmission of certain LSAs is 903 necessary, the retransmitted LSAs are always carried by unicast Link 904 State Update packets. For more information on the reliable flooding 905 of LSAs, consult Section XXXX. 907 0 1 2 3 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Version # | 4 | Packet length | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Router ID | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Area ID | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Checksum | Instance ID | 0 | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | # LSAs | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | | 921 +- +-+ 922 | LSAs | 923 +- +-+ 924 | ... | 926 # LSAs 927 The number of LSAs included in this update. 929 The body of the Link State Update packet consists of a list of LSAs. 930 Each LSA begins with a common 20 byte header, described in Section 931 A.4.2. Detailed formats of the different types of LSAs are described 932 in Section A.4. 934 A.3.6 The Link State Acknowledgment packet 936 Link State Acknowledgment Packets are OSPF packet type 5. To make 937 the flooding of LSAs reliable, flooded LSAs are explicitly 938 acknowledged. This acknowledgment is accomplished through the 939 sending and receiving of Link State Acknowledgment packets. 940 Multiple LSAs can be acknowledged in a single Link State 941 Acknowledgment packet. 943 Depending on the state of the sending interface and the sender of 944 the corresponding Link State Update packet, a Link State 945 Acknowledgment packet is sent either to the multicast address 946 AllSPFRouters, to the multicast address AllDRouters, or as a 947 unicast. The sending of Link State Acknowledgement packets is 948 documented in Section 13.5 of [Ref1]. The reception of Link State 949 Acknowledgement packets is documented in Section 13.7 of [Ref1]. 951 The format of this packet is similar to that of the Data Description 952 packet. The body of both packets is simply a list of LSA headers. 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Version # | 5 | Packet length | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Router ID | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Area ID | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Checksum | Instance ID | 0 | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | | 966 +- -+ 967 | | 968 +- An LSA Header -+ 969 | | 970 +- -+ 971 | | 972 +- -+ 973 | | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | ... | 977 Each acknowledged LSA is described by its LSA header. The LSA 978 header is documented in Section A.4.2. It contains all the 979 information required to uniquely identify both the LSA and the LSA's 980 current instance. 982 A.4 LSA formats 984 This memo defines seven distinct types of LSAs. Each LSA begins 985 with a standard 20 byte LSA header. This header is explained in 986 Section A.4.2. Succeeding sections then diagram the separate LSA 987 types. 989 Each LSA describes a piece of the OSPF routing domain. Every router 990 originates a router-LSA. A network-LSA is advertised for each link 991 by its Designated Router. A router's link-local addresses are 992 advertised to its neighbors in link-LSAs. IPv6 prefixes are 993 advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs and 994 AS-external-LSAs. Location of specific routers can be advertised 995 across area boundaries in inter-area-router-LSAs. All LSAs are then 996 flooded throughout the OSPF routing domain. The flooding algorithm 997 is reliable, ensuring that all routers have the same collection of 998 LSAs. (See Section XXXX for more information concerning the 999 flooding algorithm). This collection of LSAs is called the link- 1000 state database. 1002 From the link state database, each router constructs a shortest path 1003 tree with itself as root. This yields a routing table (see Section 1004 11 of [Ref1]). For the details of the routing table build process, 1005 see Section XXXX. 1007 A.4.1 IPv6 Prefix Representation 1009 IPv6 address prefixes are always represented by a PrefixLength, 1010 representing the length in bits of the significant part of the 1011 prefix (value 0 - 128 inclusive), an 8-bit PrefixOptions field, and 1012 then a variable amount of prefix information. The prefix 1013 information is always an even multiple of 32-bit words long, and is 1014 padded with zero bits to the next 32-bit word boundary. The length 1015 of the prefix information, in 32-bit words, is therefore 1016 ((PrefixLength + 31) / 32). 1018 The default route is represented by a prefix of length 0. 1020 A.4.1.1 Prefix Options 1022 Each prefix is advertised along with an 8-bit field of capabilities. 1023 These serve as input to the various routing calculations, allowing, 1024 for example, certain prefixes to be ignored in some cases, or to be 1025 marked as not readvertisable in others. 1027 0 1 2 3 4 5 6 7 1028 +--+--+--+--+--+--+--+--+ 1029 | | | | | P|MC|LA|NU| 1030 +--+--+--+--+--+--+--+--+ 1032 The Prefix Options field 1034 NU-bit 1035 The "no unicast" capability bit. If set, the prefix should be 1036 excluded from IPv6 unicast calculations, otherwise it should be 1037 included. 1039 LA-bit 1040 The "local address" capability bit. If set, the prefix is 1041 actually an IPv6 interface address of the advertising router. 1043 MC-bit 1044 The "multicast" capability bit. If set, the prefix should be 1045 included in IPv6 multicast routing calculations, otherwise it 1046 should be excluded. 1048 P-bit 1049 The "propagate" bit. Set on NSSA area prefixes that should be 1050 readvertised at the NSSA area border. 1052 A.4.2 The LSA header 1054 All LSAs begin with a common 20 byte header. This header contains 1055 enough information to uniquely identify the LSA (LS type, Link State 1056 ID, and Advertising Router). Multiple instances of the LSA may 1057 exist in the routing domain at the same time. It is then necessary 1058 to determine which instance is more recent. This is accomplished by 1059 examining the LS age, LS sequence number and LS checksum fields that 1060 are also contained in the LSA header. 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | LS age | LS type | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Link State ID | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Advertising Router | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | LS sequence number | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | LS checksum | length | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 LS age 1077 The time in seconds since the LSA was originated. 1079 LS type 1080 The type of the LSA. Each LSA type has a separate advertisement 1081 format. See Section A.4.2.1 for a detailed description of LS 1082 type. 1084 Link State ID 1085 Together with LS type and Advertising Router, uniquely 1086 identifies the LSA in the link-state database. 1088 Advertising Router 1089 The Router ID of the router that originated the LSA. For 1090 example, in network-LSAs this field is equal to the Router ID of 1091 the network's Designated Router. 1093 LS sequence number 1094 Detects old or duplicate LSAs. Successive instances of an LSA 1095 are given successive LS sequence numbers. See Section 12.1.6 in 1096 [Ref1] for more details. 1098 LS checksum 1099 The Fletcher checksum of the complete contents of the LSA, 1100 including the LSA header but excluding the LS age field. See 1101 Section 12.1.7 in [Ref1] for more details. 1103 length 1104 The length in bytes of the LSA. This includes the 20 byte LSA 1105 header. 1107 A.4.2.1 LS type 1109 The LS type field indicates the function performed by the LSA. The 1110 high-order three bits of LS type encode generic properties of the 1111 LSA, while the remainder (called LSA function code) indicate the 1112 LSA's specific functionality. The format of the LS type is as 1113 follows: 1115 1 1116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1117 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1118 |U |S2|S1| LSA Function Code | 1119 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1121 The U bit indicates how the LSA should be handled by a router which 1122 does not recognize its function code. Its values are: 1124 U-bit LSA Handling 1125 ____________________________________________________________ 1126 0 Store and flood the LSA, as if type understood 1127 1 Treat the LSA as if it had link-local flooding scope 1129 The S1 and S2 bits indicate the flooding scope of the LSA. The 1130 values are: 1132 S2 S1 Flooding Scope 1133 _______________________________________________________________________ 1134 0 0 Link-Local Scoping. Flooded only on link it is originated on. 1135 0 1 Area Scoping. Flooded to all routers in the originating area 1136 1 0 AS Scoping. Flooded to all routers in the AS 1137 1 1 Reserved 1139 The LSA function codes are defined as follows. The origination and 1140 processing of these LSA function codes are defined elsewhere in this 1141 memo, except for the group-membership-LSA (see [Ref7]) and the 1142 Type-7-LSA (see [Ref8]). Each LSA function code also implies a 1143 specific setting for the U, S1 and S2 bits, as shown below. 1145 LSA function code LS Type Description 1146 ___________________________________________________ 1147 1 0x2001 Router-LSA 1148 2 0x2002 Network-LSA 1149 3 0x2003 Inter-Area-Prefix-LSA 1150 4 0x2004 Inter-Area-Router-LSA 1151 5 0x4005 AS-External-LSA 1152 6 0x2006 Group-membership-LSA 1153 7 0x2007 Type-7-LSA 1154 8 0x0008 Link-LSA 1155 9 0x2009 Intra-Area-Prefix-LSA 1156 A.4.3 Router-LSAs 1158 Router-LSAs have LS type equal to 0x2001. Each router in an area 1159 originates one or more router-LSAs. The complete collection of 1160 router-LSAs originated by the router describe the state and cost of 1161 the router's interfaces to the area. For details concerning the 1162 construction of router-LSAs, see Section XXXX. Router-LSAs are 1163 flooded throughout a single area only. 1165 0 1 2 3 1166 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 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | LS age |0|0|1| 1 | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Link State ID | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Advertising Router | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | LS sequence number | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | LS checksum | length | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | 0 |V|E|B| Options | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Type | 0 | Metric | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Interface ID | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Neighbor Interface ID | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | Neighbor Router ID | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | ... | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Type | 0 | Metric | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Interface ID | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Neighbor Interface ID | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Neighbor Router ID | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | ... | 1200 A single router may originate one or more Router LSAs, distinguished 1201 by their Link-State IDs (which are chosen arbitrarily by the 1202 originating router). The Options field and V, E and B bits should 1203 be the same in all Router LSAs from a single originator. However, 1204 in the case of a mismatch the values in the LSA with the lowest Link 1205 State ID take precedence. When more than one Router LSA is received 1206 from a single router, the links are processed as if concatenated 1207 into a single LSA. 1209 bit V 1210 When set, the router is an endpoint of one or more fully 1211 adjacent virtual links having the described area as Transit area 1212 (V is for virtual link endpoint). 1214 bit E 1215 When set, the router is an AS boundary router (E is for 1216 external). 1218 bit B 1219 When set, the router is an area border router (B is for border). 1221 Options 1222 The optional capabilities supported by the router, as documented 1223 in Section A.2. 1225 The following fields are used to describe each router interface. 1226 The Type field indicates the kind of interface being described. It 1227 may be an interface to a transit network, a point-to-point 1228 connection to another router or a virtual link. The values of all 1229 the other fields describing a router interface depend on the 1230 interface's Type field. 1232 Type 1233 The kind of interface being described. One of the following: 1235 Type Description 1236 __________________________________________________ 1237 1 Point-to-point connection to another router 1238 2 Connection to a transit network 1239 3 Reserved 1240 4 Virtual link 1241 Metric 1242 The cost of using this router interface, for outbound traffic. 1244 Interface ID 1245 The Interface ID assigned to the interface being described. See 1246 Sections XXXX and C.3. 1248 Neighbor Interface ID 1249 The Interface ID the neighbor router (or the attached link's 1250 Designated Router, for Type 2 interfaces) has been advertising 1251 in hello packets sent on the atached link. n 1253 Neighbor Router ID 1254 The Router ID the neighbor router (or the attached link's 1255 Designated Router, for Type 2 interfaces). 1257 For Type 2 links, the combination of Neighbor Interface ID and 1258 Neighbor Router ID allows the network-LSA for the attached link 1259 to be found in the link-state database. 1261 A.4.4 Network-LSAs 1263 Network-LSAs have LS type equal to 0x2002. A network-LSA is 1264 originated for each broadcast and NBMA link in the area which 1265 supports two or more routers. The network-LSA is originated by the 1266 link's Designated Router. The LSA describes all routers attached to 1267 the link, including the Designated Router itself. The LSA's Link 1268 State ID field is set to the Interface ID that the Designated Router 1269 has been advertising in Hello packets on the link. 1271 The distance from the network to all attached routers is zero. This 1272 is why the metric fields need not be specified in the network-LSA. 1273 For details concerning the construction of network-LSAs, see Section 1274 XXXX. 1276 0 1 2 3 1277 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 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | LS age |0|0|1| 2 | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Link State ID | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Advertising Router | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | LS sequence number | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | LS checksum | length | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | 0 | Options | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Attached Router | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | ... | 1295 Attached Router 1296 The Router IDs of each of the routers attached to the link. 1297 Actually, only those routers that are fully adjacent to the 1298 Designated Router are listed. The Designated Router includes 1299 itself in this list. The number of routers included can be 1300 deduced from the LSA header's length field. 1302 A.4.5 Inter-Area-Prefix-LSAs 1304 Inter-Area-Prefix-LSAs have LS type equal to 0x2003. These LSAs are 1305 originated by area border routers, and describe routes to IPv6 1306 address prefixes that belong to other areas. A separate Inter-Area- 1307 Prefix-LSA is originated for each IPv6 address prefix. For details 1308 concerning the construction of Inter-Area-Prefix-LSAs, see Section 1309 XXXX. 1311 For stub areas, Inter-Area-Prefix-LSAs can also be used to describe 1312 a (per-area) default route. Default summary routes are used in stub 1313 areas instead of flooding a complete set of external routes. When 1314 describing a default summary route, the Inter-Area-Prefix-LSA's 1315 PrefixLength is set to 0. 1317 0 1 2 3 1318 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 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | LS age |0|0|1| 3 | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Link State ID | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Advertising Router | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | LS sequence number | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | LS checksum | length | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | 0 | Metric | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | PrefixLength | PrefixOptions | (0) | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Address Prefix | 1335 | ... | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 Metric 1339 The cost of this route. Expressed in the same units as the 1340 interface costs in the router-LSAs. When the Inter-Area-Prefix- 1341 LSA is describing a route to a range of addresses (see Section 1342 C.2) the cost is set to the maximum cost to any reachable 1343 component of the address range. 1345 PrefixLength, PrefixOptions and Address Prefix 1346 Representation of the IPv6 address prefix, as described in 1347 Section A.4.1. 1349 A.4.6 Inter-Area-Router-LSAs 1351 Inter-Area-Router-LSAs have LS type equal to 0x2004. These LSAs are 1352 originated by area border routers, and describe routes to routers in 1353 other areas. (To see why it is necessary to advertise the location 1354 of each ASBR, consult Section 16.4 in [Ref1].) Each LSA describes a 1355 route to a single router. For details concerning the construction of 1356 Inter-Area-Router-LSAs, see Section XXXX. 1358 0 1 2 3 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | LS age |0|0|1| 4 | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Link State ID | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Advertising Router | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | LS sequence number | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | LS checksum | length | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | 0 | Options | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | 0 | Metric | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Destination Router ID | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 Options 1379 The optional capabilities supported by the router, as documented 1380 in Section A.2. 1382 Metric 1383 The cost of this route. Expressed in the same units as the 1384 interface costs in the router-LSAs. 1386 Destination Router ID 1387 The Router ID of the router being described by the LSA. 1389 A.4.7 AS-external-LSAs 1391 AS-external-LSAs have LS type equal to 0x2005. These LSAs are 1392 originated by AS boundary routers, and describe destinations 1393 external to the AS. Each LSA describes a route to a single IPv6 1394 address prefix. For details concerning the construction of AS- 1395 external-LSAs, see Section XXXX. 1397 AS-external-LSAs can be used to describe a default route. Default 1398 routes are used when no specific route exists to the destination. 1399 When describing a default route, the AS-external-LSA's PrefixLength 1400 is set to 0. 1402 0 1 2 3 1403 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 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | LS age |0|0|1| 5 | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Link State ID | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Advertising Router | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | LS sequence number | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | LS checksum | length | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | |E|F| Metric | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | PrefixLength | PrefixOptions | Referenced LS Type | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Address Prefix | 1420 | ... | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | | 1423 +- -+ 1424 | | 1425 +- Forwarding Address (Optional) -+ 1426 | | 1427 +- -+ 1428 | | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | Referenced Link State ID (Optional) | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 bit E 1434 The type of external metric. If bit E is set, the metric 1435 specified is a Type 2 external metric. This means the metric is 1436 considered larger than any intra-AS path. If bit E is zero, the 1437 specified metric is a Type 1 external metric. This means that 1438 it is expressed in the same units as the link state metric 1439 (i.e., the same units as interface cost). 1441 bit F 1442 If set, a forwarding address has been included in the LSA. 1444 Metric 1445 The cost of this route. Interpretation depends on the external 1446 type indication (bit E above). 1448 PrefixLength, PrefixOptions and Address Prefix 1449 Representation of the IPv6 address prefix, as described in 1450 Section A.4.1. 1452 Referenced LS type 1453 If non-zero, an LSA with this LS type is to be associated with 1454 this LSA (see Referenced Link State ID below). 1456 Forwarding address 1457 A fully qualified IPv6 address (128 bits). Included in the LSA 1458 if and only if bit F has been set. If included, Data traffic 1459 for the advertised destination and TOS will be forwarded to this 1460 address. Must not be set to the IPv6 Unspecified Address 1461 (0:0:0:0:0:0:0:0). 1463 Referenced Link State ID 1464 Included if and only if Reference LS Type is non-zero. If 1465 included, additional information concerning the advertised 1466 external route can be found in the LSA having LS type equal to 1467 "Referenced LS Type", Link State ID equal to "Referenced Link 1468 State ID" and Advertising Router the same as that specified in 1469 the AS-external-LSA's link state header. This additional 1470 information is not used by the OSPF protocol itself. It may be 1471 used to communicate information between AS boundary routers; the 1472 precise nature of such information is outside the scope of this 1473 specification. 1475 If Forwarding address and Referenced Link State ID are both included 1476 in the AS-external-LSA, Forwarding Address always comes first. 1478 A.4.8 Link-LSAs 1480 Link-LSAs have LS type equal to 0x0008. A router originates a 1481 separate Link-LSA for each link it is attached to. These LSAs have 1482 local-link flooding scope; they are never flooded beyond the link 1483 that they are associated with. Link-LSAs have three purposes: 1) 1484 they provide the router's link-local address to all other routers 1485 attached to the link and 2) they inform other routers attached to 1486 the link of a list of IPv6 prefixes to associate with the link and 1487 3) they allow the router to assert a collection of Options bits to 1488 associate with the Network-LSA that will be originated for the link. 1490 A link-LSA's Link State ID is set equal to the originating router's 1491 Interface ID on the link. 1492 0 1 2 3 1493 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 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | LS age |0|0|0| 8 | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Link State ID | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Advertising Router | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | LS sequence number | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | LS checksum | length | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | Rtr Pri | Options | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | | 1508 +- -+ 1509 | | 1510 +- Link-local Interface Address -+ 1511 | | 1512 +- -+ 1513 | | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | # prefixes | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | PrefixLength | PrefixOptions | (0) | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | Address Prefix | 1520 | ... | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | ... | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | PrefixLength | PrefixOptions | (0) | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Address Prefix | 1527 | ... | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 Rtr Pri 1531 The Router Priority of the interface attaching the originating 1532 router to the link. 1534 Options 1535 The set of Options bits that the router would like set in the 1536 Network-LSA that will be originated for the link. 1538 Link-local Interface Address 1539 The originating router's link-local interface address on the 1540 link. 1542 # prefixes 1543 The number of IPv6 address prefixes contained in the LSA. 1545 The rest of the link-LSA contains a list of IPv6 prefixes to be 1546 associated with the link. 1548 PrefixLength, PrefixOptions and Address Prefix 1549 Representation of an IPv6 address prefix, as described in 1550 Section A.4.1. 1552 A.4.9 Intra-Area-Prefix-LSAs 1554 Intra-Area-Prefix-LSAs have LS type equal to 0x2009. Intra-Area- 1555 Prefix-LSAs allow a router to associate one or more IPv6 address 1556 prefixes with a router (itself) or a transit link (one of the 1557 originating router's attached links). These prefixes are then 1558 processed as "stub links" during the OSPF intra-area routing 1559 calculation (see Section XXXX). 1561 A router can originate multiple Intra-Area-Prefix-LSAs for each 1562 router or transit network; each such LSA is distinguished by its 1563 Link State ID. 1565 0 1 2 3 1566 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 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | LS age |0|0|1| 9 | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Link State ID | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Advertising Router | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | LS sequence number | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | LS checksum | length | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | # prefixes | Referenced LS type | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Referenced Link State ID | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Referenced Advertising Router | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | PrefixLength | PrefixOptions | Metric | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | Address Prefix | 1587 | ... | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | ... | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | PrefixLength | PrefixOptions | Metric | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | Address Prefix | 1594 | ... | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 # prefixes 1598 The number of IPv6 address prefixes contained in the LSA. 1600 Referenced LS type, Referenced Link State ID and Referenced 1601 Advertising Router" Identifies the router-LSA or network-LSA 1602 with which the IPv6 address prefixes should be associated. If 1603 Referenced LS type is 1, the prefixes are associated with a 1604 router-LSA, Referenced Link State ID should be 0 and Referenced 1605 Advertising Router should be the originating router's Router ID. 1606 If Referenced LS type is 2, the prefixes are associated with a 1607 network-LSA, Referenced Link State ID should be the Interface ID 1608 of the link's Designated Router and Referenced Advertising 1609 Router should be the Designated Router's Router ID. 1611 The rest of the Intra-Area-Prefix-LSA contains a list of IPv6 1612 prefixes to be associated with the router or transit link, together 1613 with the cost of each prefix. 1615 PrefixLength, PrefixOptions and Address Prefix 1616 Representation of an IPv6 address prefix, as described in 1617 Section A.4.1. 1619 Metric 1620 The cost of this prefix. Expressed in the same units as the 1621 interface costs in the router-LSAs. 1623 B. Architectural Constants 1625 Architectural coonstants for the OSPF protocol are defined in 1626 Appendix C of [Ref1]. The only difference for OSPF for IPv6 is that 1627 DefaultDestination is encoded as a prefix of length 0 (see Section 1628 A.4.1). 1630 C. Configurable Constants 1632 The OSPF protocol has quite a few configurable parameters. These 1633 parameters are listed below. They are grouped into general 1634 functional categories (area parameters, interface parameters, etc.). 1635 Sample values are given for some of the parameters. 1637 Some parameter settings need to be consistent among groups of 1638 routers. For example, all routers in an area must agree on that 1639 area's parameters, and all routers attached to a network must agree 1640 on that network's HelloInterval and RouterDeadInterval. 1642 Some parameters may be determined by router algorithms outside of 1643 this specification (e.g., the address of a host connected to the 1644 router via a SLIP line). From OSPF's point of view, these items are 1645 still configurable. 1647 C.1 Global parameters 1649 In general, a separate copy of the OSPF protocol is run for each 1650 area. Because of this, most configuration parameters are 1651 defined on a per-area basis. The few global configuration 1652 parameters are listed below. 1654 Router ID 1655 This is a 32-bit number that uniquely identifies the router 1656 in the Autonomous System. If a router's OSPF Router ID is 1657 changed, the router's OSPF software should be restarted 1658 before the new Router ID takes effect. Before restarting in 1659 order to change its Router ID, the router should flush its 1660 self-originated LSAs from the routing domain (see Section 1661 14.1 of [Ref1]), or they will persist for up to MaxAge 1662 minutes. 1664 C.2 Area parameters 1666 All routers belonging to an area must agree on that area's 1667 configuration. Disagreements between two routers will lead to 1668 an inability for adjacencies to form between them, with a 1669 resulting hindrance to the flow of routing protocol and data 1670 traffic. The following items must be configured for an area: 1672 Area ID 1673 This is a 32-bit number that identifies the area. The Area 1674 ID of 0 is reserved for the backbone. 1676 List of address ranges 1677 Address ranges control the advertisement of routes across 1678 area boundaries. Each address range consists of the 1679 following items: 1681 [IPv6 prefix, prefix length] 1682 Describes the collection of IPv6 addresses contained 1683 in the address range. 1685 Status Set to either Advertise or DoNotAdvertise. Routing 1686 information is condensed at area boundaries. 1687 External to the area, at most a single route is 1688 advertised (via a inter-area-prefix-LSA) for each 1689 address range. The route is advertised if and only 1690 if the address range's Status is set to Advertise. 1691 Unadvertised ranges allow the existence of certain 1692 networks to be intentionally hidden from other 1693 areas. Status is set to Advertise by default. 1695 ExternalRoutingCapability 1696 Whether AS-external-LSAs will be flooded into/throughout the 1697 area. If AS-external-LSAs are excluded from the area, the 1698 area is called a "stub". Internal to stub areas, routing to 1699 external destinations will be based solely on a default 1700 inter-area route. The backbone cannot be configured as a 1701 stub area. Also, virtual links cannot be configured through 1702 stub areas. For more information, see Section 3.6 of 1703 [Ref1]. 1705 StubDefaultCost 1706 If the area has been configured as a stub area, and the 1707 router itself is an area border router, then the 1708 StubDefaultCost indicates the cost of the default inter- 1709 area-prefix-LSA that the router should advertise into the 1710 area. See Section XXXX for more information. 1712 C.3 Router interface parameters 1714 Some of the configurable router interface parameters (such as 1715 Area ID, HelloInterval and RouterDeadInterval) actually imply 1716 properties of the attached links, and therefore must be 1717 consistent across all the routers attached to that link. The 1718 parameters that must be configured for a router interface are: 1720 IPv6 link-local address 1721 The IPv6 link-local address associated with this interface. 1722 May be learned through auto-configuration. 1724 Area ID 1725 The OSPF area to which the attached link belongs. 1727 Instance ID 1728 The OSPF protocol instance associated with this OSPF 1729 interface. Defaults to 0. 1731 Interface ID 1732 32-bit number uniquely identifying this interface among the 1733 collection of this router's interfaces. For example, in some 1734 implementations it may be possible to use the MIB-II 1735 IfIndex. 1737 IPv6 prefixes 1738 The list of IPv6 prefixes to associate with the link. These 1739 will be advertised in intra-area-prefix-LSAs. 1741 Interface output cost(s) 1742 The cost of sending a packet on the interface, expressed in 1743 the link state metric. This is advertised as the link cost 1744 for this interface in the router's router-LSA. The interface 1745 output cost must always be greater than 0. 1747 RxmtInterval 1748 The number of seconds between LSA retransmissions, for 1749 adjacencies belonging to this interface. Also used when 1750 retransmitting Database Description and Link State Request 1751 Packets. This should be well over the expected round-trip 1752 delay between any two routers on the attached link. The 1753 setting of this value should be conservative or needless 1754 retransmissions will result. Sample value for a local area 1755 network: 5 seconds. 1757 InfTransDelay 1758 The estimated number of seconds it takes to transmit a Link 1759 State Update Packet over this interface. LSAs contained in 1760 the update packet must have their age incremented by this 1761 amount before transmission. This value should take into 1762 account the transmission and propagation delays of the 1763 interface. It must be greater than 0. Sample value for a 1764 local area network: 1 second. 1766 Router Priority 1767 An 8-bit unsigned integer. When two routers attached to a 1768 network both attempt to become Designated Router, the one 1769 with the highest Router Priority takes precedence. If there 1770 is still a tie, the router with the highest Router ID takes 1771 precedence. A router whose Router Priority is set to 0 is 1772 ineligible to become Designated Router on the attached link. 1773 Router Priority is only configured for interfaces to 1774 broadcast and NBMA networks. 1776 HelloInterval 1777 The length of time, in seconds, between the Hello Packets 1778 that the router sends on the interface. This value is 1779 advertised in the router's Hello Packets. It must be the 1780 same for all routers attached to a common link. The smaller 1781 the HelloInterval, the faster topological changes will be 1782 detected; however, more OSPF routing protocol traffic will 1783 ensue. Sample value for a X.25 PDN: 30 seconds. Sample 1784 value for a local area network (LAN): 10 seconds. 1786 RouterDeadInterval 1787 After ceasing to hear a router's Hello Packets, the number 1788 of seconds before its neighbors declare the router down. 1789 This is also advertised in the router's Hello Packets in 1790 their RouterDeadInterval field. This should be some 1791 multiple of the HelloInterval (say 4). This value again 1792 must be the same for all routers attached to a common link. 1794 C.4 Virtual link parameters 1796 Virtual links are used to restore/increase connectivity of the 1797 backbone. Virtual links may be configured between any pair of 1798 area border routers having interfaces to a common (non-backbone) 1799 area. The virtual link appears as an unnumbered point-to-point 1800 link in the graph for the backbone. The virtual link must be 1801 configured in both of the area border routers. 1803 A virtual link appears in router-LSAs (for the backbone) as if 1804 it were a separate router interface to the backbone. As such, 1805 it has most of the parameters associated with a router interface 1806 (see Section C.3). Virtual links do not have link-local 1807 addresses, but instead use one of the router's global-scope or 1808 site-local IPv6 addresses as the IP source in OSPF protocol 1809 packets it sends along the virtual link. Router Priority is not 1810 used on virtual links. Interface output cost is not configured 1811 on virtual links, but is dynamically set to be the cost of the 1812 intra-area path between the two endpoint routers. The parameter 1813 RxmtInterval must be configured, and should be well over the 1814 expected round-trip delay between the two routers. This may be 1815 hard to estimate for a virtual link; it is better to err on the 1816 side of making it too large. 1818 A virtual link is defined by the following two configurable 1819 parameters: the Router ID of the virtual link's other endpoint, 1820 and the (non-backbone) area through which the virtual link runs 1821 (referred to as the virtual link's Transit area). Virtual links 1822 cannot be configured through stub areas. 1824 C.5 NBMA network parameters 1826 OSPF treats an NBMA network much like it treats a broadcast 1827 network. Since there may be many routers attached to the 1828 network, a Designated Router is selected for the network. This 1829 Designated Router then originates a network-LSA, which lists all 1830 routers attached to the NBMA network. 1832 However, due to the lack of broadcast capabilities, it may be 1833 necessary to use configuration parameters in the Designated 1834 Router selection. These parameters will only need to be 1835 configured in those routers that are themselves eligible to 1836 become Designated Router (i.e., those router's whose Router 1837 Priority for the network is non-zero), and then only if no 1838 automatic procedure for discovering neighbors exists: 1840 List of all other attached routers 1841 The list of all other routers attached to the NBMA network. 1842 Each router is configured with its Router ID and IPv6 link- 1843 local address on the network. Also, for each router listed, 1844 that router's eligibility to become Designated Router must 1845 be defined. When an interface to a NBMA network comes up, 1846 the router sends Hello Packets only to those neighbors 1847 eligible to become Designated Router, until the identity of 1848 the Designated Router is discovered. 1850 PollInterval 1851 If a neighboring router has become inactive (Hello Packets 1852 have not been seen for RouterDeadInterval seconds), it may 1853 still be necessary to send Hello Packets to the dead 1854 neighbor. These Hello Packets will be sent at the reduced 1855 rate PollInterval, which should be much larger than 1856 HelloInterval. Sample value for a PDN X.25 network: 2 1857 minutes. 1859 C.6 Point-to-MultiPoint network parameters 1861 On Point-to-MultiPoint networks, it may be necessary to 1862 configure the set of neighbors that are directly reachable over 1863 the Point-to-MultiPoint network. Each neighbor is configured 1864 with its Router ID and IPv6 link-local address on the network. 1865 Designated Routers are not elected on Point-to-MultiPoint 1866 networks, so the Designated Router eligibility of configured 1867 neighbors is undefined. 1869 C.7 Host route parameters 1871 Host routes are advertised in intra-area-prefix-LSAs as fully 1872 qualified IPv6 prefixes (i.e., prefix length set equal to 128 1873 bits). They indicate either router interfaces to point-to-point 1874 networks, looped router interfaces, or IPv6 hosts that are 1875 directly connected to the router (e.g., via a PPP connection). 1876 For each host directly connected to the router, the following 1877 items must be configured: 1879 Host IPv6 address 1880 The IPv6 address of the host. 1882 Cost of link to host 1883 The cost of sending a packet to the host, in terms of the 1884 link state metric. However, since the host probably has only 1885 a single connection to the internet, the actual configured 1886 cost(s) in many cases is unimportant (i.e., will have no 1887 effect on routing). 1889 Area ID 1890 The OSPF area to which the host belongs. 1892 Security Considerations 1894 When running over IPv6, OSPF relies on the IP Authentication Header 1895 (see [Ref19]) and the IP Encapsulating Security Payload (see 1896 [Ref120]) to ensure integrity and authentication/confidentiality of 1897 routing exchanges. 1899 Authors Addresses 1901 Rob Coltun 1902 FORE Systems 1903 Phone: (301) 571-2521 1904 email: rcoltun@fore.com 1906 Dennis Ferguson 1907 Ipsilon Networks 1908 dennis@Ipsilon.COM 1910 John Moy 1911 Cascade Communications Corp. 1912 5 Carlisle Road 1913 Westford, MA 01886 1914 Phone: 508-952-1367 1915 Fax: 508-692-9214 1916 Email: jmoy@casc.com 1918 This document expires in August 1996.