Network Working Group R. Coltun Internet Draft FORE Systems Expiration Date: August 1996 D. Ferguson File name: draft-ietf-ospf-ospfv6-01.txt Ipsilon Networks Network Working Group J. Moy Internet Draft Cascade Communications Corp. February 1996 OSPF for IPv6 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs a a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. Coltun et al [Page 1]
Internet Draft OSPF for IPv6 February 1996 Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4l, even with the larger IPv6 addresses. Most field- and packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. Please send comments to ospf@gated.cornell.edu. Coltun et al [Page 2]
Internet Draft OSPF for IPv6 February 1996 Table of Contents 1 Introduction ........................................... 5 1.1 Terminology ............................................ 5 2 Differences from OSPF for IPv4 ......................... 5 2.1 Protocol processing per-link, not per-subnet ........... 5 2.2 Removal of addressing semantics ........................ 6 2.3 Addition of Flooding scope ............................. 6 2.4 Explicit support for multiple instances per link ....... 7 2.5 Use of link-local addresses ............................ 7 2.6 Authentication changes ................................. 7 2.7 Packet format changes .................................. 8 2.8 LSA format changes ..................................... 8 2.9 Handling unknown LSA types ............................ 10 2.10 Removal of TOS ........................................ 10 3 Implementation details ................................ 11 References ............................................ 12 A OSPF data formats ..................................... 14 A.1 Encapsulation of OSPF packets ......................... 14 A.2 The Options field ..................................... 16 A.3 OSPF Packet Formats ................................... 18 A.3.1 The OSPF packet header ................................ 19 A.3.2 The Hello packet ...................................... 21 A.3.3 The Database Description packet ....................... 23 A.3.4 The Link State Request packet ......................... 25 A.3.5 The Link State Update packet .......................... 26 A.3.6 The Link State Acknowledgment packet .................. 27 A.4 LSA formats ........................................... 28 A.4.1 IPv6 Prefix Representation ............................ 30 A.4.1.1 Prefix Options ........................................ 31 A.4.2 The LSA header ........................................ 32 A.4.2.1 LS type ............................................... 34 A.4.3 Router-LSAs ........................................... 36 A.4.4 Network-LSAs .......................................... 39 A.4.5 Inter-Area-Prefix-LSAs ................................ 40 A.4.6 Inter-Area-Router-LSAs ................................ 41 A.4.7 AS-external-LSAs ...................................... 42 A.4.8 Link-LSAs ............................................. 44 A.4.9 Intra-Area-Prefix-LSAs ................................ 46 B Architectural Constants ............................... 48 C Configurable Constants ................................ 48 C.1 Global parameters ..................................... 48 C.2 Area parameters ....................................... 48 C.3 Router interface parameters ........................... 49 C.4 Virtual link parameters ............................... 51 C.5 NBMA network parameters ............................... 52 C.6 Point-to-MultiPoint network parameters ................ 53 C.7 Host route parameters ................................. 53 Coltun et al [Page 3]
Internet Draft OSPF for IPv6 February 1996 Security Considerations ............................... 54 Authors' Addresses .................................... 54 Coltun et al [Page 4]
Internet Draft OSPF for IPv6 February 1996 1. Introduction This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. This document is organized as follows. Section 2 describes the differences betweed OSPF for IPv4 and OSPF for IPv6 in detail. Section 3 provides implementation details for the changes. Appendix A gives the OSPF for IPv6 packet and LSA formats. Appendix B lists the OSPF architectural constants. Appendix C describes configuration parameters. 1.1. Terminology This document attempts to use terms from both the OSPF for IPv4 specification ([Ref1]) and the IPv6 protocol specifications ([Ref14]). This has produced a mixed result. Most of the terms used both by OSPF and IPv6 have roughly the same meaning (e.g., interfaces). However, there are a few conflicts. IPv6 uses "link" similarly to IPv4 OSPF's "subnet" or "network". In this case, we have chosen to use IPv6's "link" terminology. "Link" replaces OSPF's "subnet" and "network" in most places in this document, although OSPF's Network-LSA remains unchanged (and possibly unfortunately, a new Link-LSA has also been created). The names of some of the OSPF LSAs have also changed. See Section 2.8 for details. 2. Differences from OSPF for IPv4 Most of the algorithms from OSPF for IPv4 [Ref1] have preserved in OSPF for IPv6. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. The following subsections describe the differences between this document and [Ref1]. 2.1. Protocol processing per-link, not per-subnet IPv6 uses the term "link" to indicate "a communication facility or medium over which nodes can communicate at the link layer" ([Ref14]). "Interfaces" connect to links. Multiple IP subnets can be assigned to a single link, and two nodes can talk Coltun et al [Page 5]
Internet Draft OSPF for IPv6 February 1996 directly over a single link, even if they do not share a common IP subnet (IPv6 prefix). For this reason, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet. The terms "network" and "subnet" used in the IPv4 OSPF specification ([Ref1]) should generally be relaced by link. Likewise, an OSPF interface now connects to a link instead of and IP subnet, etc. This change affects the receiving of OSPF protocol packets, and the contents of Hello Packets and Network-LSAs. 2.2. Removal of addressing semantics In OSPF for IPv6, addressing semantics have been removed from the OSPF protocol packets and the main LSA types, leaving a network-protocol-independent core. In particular: o IPv6 Addresses are not present in OSPF packets, except for in LSA payloads carried by the Link State Update Packets. See Section 2.7 for details. o Router-LSAs and Network-LSAs no longer contain network addresses, but simply express topology information. See Section 2.8 for details. o OSPF Router IDs, Area IDs and LSA Link State IDs remain at the IPv4 size of 32-bits. They can no longer be assigned as (IPv6) addresses. o Neighboring routers are now always identified by Router ID, where previously they had been identified by IP address on broadcast and NBMA "networks". 2.3. Addition of Flooding scope Flooding scope for LSAs has been generalized and is now explicitly coded in the LSA's LS type field. There are now three separate flooding scopes for LSAs: o Link-local scope. LSA is flooded only on the local link, and no further. Used for the new Link-LSA (see Section A.4.8). o Area scope. LSA is flooded throughout a single OSPF area only. Used for Router-LSAs, Network-LSAs, Inter-Area- Prefix-LSAs, Inter-Area-Router-LSAs and Intra-Area-Prefix- LSAs. Coltun et al [Page 6]
Internet Draft OSPF for IPv6 February 1996 o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. 2.4. Explicit support for multiple instances per link OSPF now supports the ability to run multiple OSPF protocol instances on a single link. For example, this may be required on a NAP segment shared between several providers -- providers may be running a separate OSPF routing domains that want to remain separate even though they have one or more physical network segments (i.e., links) in common. In OSPF for IPv4 this was supported in a haphazard fashion using the authentication fields in the OSPF for IPv4 header. Another use for running multiple OSPF instances is if you want, for one reason or another, to have a single link belog to two or more OSPF areas. Support for multiple protocol instances on a link is accomplished via an "Instance ID" contained in the OSPF packet header and OSPF interface structures. Instance ID solely affects the reception of OSPF packets. 2.5. Use of link-local addresses On all interfaces except virtual links, OSPF packets are sent using the link-local interface address as source. A router learns the link-local interface addresses of all other routers attached to its links, and uses these addresses as next hop information for packet forwarding. On virtual links, global scope or site-local IP addresses must be used as the source for OSPF protocol packets. 2.6. Authentication changes In OSPF for IPv6, authentication has been removed from OSPF itself. The "Autype" and "Authentication" fields have been removed from the OSPF packet header, and all authentication related fields have been removed from the OSPF area and interface structures. When running over IPv6, OSPF relies on the IP Authentication Header (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to ensure integrity and authentication/confidentiality of routing exchanges. Coltun et al [Page 7]
Internet Draft OSPF for IPv6 February 1996 2.7. Packet format changes OSPF for IPv6 runs directly over IPv6. Aside from this, all addressing semantics have been removed from the OSPF packet headers, making it essentially "network-protocol independent". All addressing information is now contain in various LSA types only. In detail, changes in OSPF packet format consist of the following: o The OSPF version number has been increased from 2 to 3. o The Options field in Hello Packets and Database description Packets has been expanded to 24-bits. o The Authentication and AuType fields have been removed from the OSPF packet header (see Section 2.6). o The Hello packet now contains no address information at all, and includes a Interface ID which the originating router has assigned to uniquely identify (among its own interfaces) its interface to the link. This Interface ID becomes the Network-LSA's Link State ID, should the router become Designated Router on the link. o Two options bits have been added to the Options field for processing Router-LSAs during the SPF calculation (see Section A.2). The "V6-bit" allows routers to participate in OSPF topology distribution, but avoid the forwarding of IPv6 datagrams. The "R-bit" allows nodes to participate in OSPF topology distribution, but avoid being used to forward transit traffic. This latter option could be used in multi- homed hosts that want to participate in routing calculations. o The OSPF packet header now includes an "Instance ID" which allows multiple OSPF protocol instances to be run on a single link (see Section 2.4). 2.8. LSA format changes All addressing semantics have been removed from the LSA header, and from Router-LSAs and Network-LSAs. These two LSAs now describe the routing domain's topology in a network-protocol independent manner. New LSAs have been added to distribute IPv6 address information, and data required for next hop resolution. The names of some of IPv4's LSAs have been changed to be more Coltun et al [Page 8]
Internet Draft OSPF for IPv6 February 1996 consistent with each other. In detail, changes in LSA format consist of the following: o The Options field has been removed from the LSA header, expanded to 24 bits, and moved into the body of Router-LSAs, Network-LSAs, Inter-Area-Router-LSAs and Link-LSAs. o The LSA Type field has been expanded (into the former Options space) to 16 bits, with the upper three bits encoding flooding scope and the handling of unknow LSA types (see Section 2.9). o Addresses in LSAs are now expresses as [prefix, prefix length] instead of [address, mask] (see Section A.4.1). The default route is expressed as a prefix with length 0. o The Router and Network LSAs now have no address information, and are network-protocol-independent. o Router interface information may be spread across multiple Router LSAs. Receivers must concatenate all the Router-LSAs originated by a given router when running the SPF calculation. o A new LSA called the Link-LSA has been introduced. The LSAs have local-link flooding scope; they are never flooded beyond the link that they are associated with. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link and 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link and 3) they allow the router to assert a collection of Options bits to associate with the Network-LSA that will be originated for the link. See Section A.4.8 for details. o The Options field in the Network LSA is set to the logical OR of the Options that each router on the link advertises in its Link-LSA. o Type-3 summary-LSAs have been renamed "Inter-Area-Prefix- LSAs". Type-4 summary LSAs have been renamed "Inter-Area- Router-LSAs". o The Link State ID in Inter-Area-Prefix-LSAs, Inter-Area- Router-LSAs and AS-external-LSAs has lost its addressing semantics, and now serves solely to identify individual pieces of the Link State Database. All addresses or Router Coltun et al [Page 9]
Internet Draft OSPF for IPv6 February 1996 IDs that formerly were expressed by the Link State ID are now carried in the LSA bodies. o Network-LSAs and Link-LSAs are the only LSAs whose Link State ID carries additional meaning. For these LSAs, the Link State ID is always the Interface ID of the originating router on the link being described. For this reason, Network-LSAs and Link-LSAs are now the only LSAs that cannot be broken into arbitrarily small pieces. o A new LSA called the Inter-Area-Prefix-LSA has been introduced. This LSA carries all IPv6 prefix information that in IPv4 is included in Router-LSAs and Network-LSAs. See Section A.4.6 for details. o Inclusion of a forwarding address in AS-external-LSAs is now optional. In addition, AS-external-LSAs can now reference another LSA, for inclusion of route attributes outside the scope of the OSPF protocol itself. For example, this can be used to attach tags to OSPF external routes as in [Ref5], or BGP path attributes as proposed in [Ref10]. 2.9. Handling unknown LSA types Handling of unknown LSA types has been made more flexible so that, based on LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood (desirable for things like the proposed External Attributes LSA in [Ref10]). This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see Section A.4.2.1). The IPv4 OSPF behavior of simply discarding unknown types is unsupported due to the desire to mix router capabilities on a single link. Discarding unknown types causes problems when the Designated Router supports fewer options than the other routers on the link. 2.10. Removal of TOS The semantics of IPv4 TOS have not been moved forward to IPv6. Therfore, support for TOS in OSPF for IPv6 has been removed. This affects both LSA formats and routing calculations. The IPv6 header does have a 24-bit Flow Label field which may be used by a source to label those packets for which it requests special handling by IPv6 routers, such as non-default quality of service or "real-time" ser- vice. The OSPF LSAs for IPv6 have Coltun et al [Page 10]
Internet Draft OSPF for IPv6 February 1996 been organized so that future extensions to support routing based on Flow Label are possible. 3. Implementation details To be written. Strategy will be to refer to IPv4 as much as possible. Only when changes are major is a section completely rewritten. Coltun et al [Page 11]
Internet Draft OSPF for IPv6 February 1996 References [Ref1] Moy, J., "OSPF Version 2", Internet Draft, <draft-ietf- ospf-version2-06.txt>, Cascade, November 1995. [Ref2] McKenzie, A., "ISO Transport Protocol specification ISO DP 8073", RFC 905, ISO, April 1984. [Ref3] McCloghrie, K., and M. Rose, "Management Information Base for network management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [Ref4] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, OARnet, September 1993. [Ref5] Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP--- OSPF Interaction", RFC1745, December 1994 [Ref6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [Ref7] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994. [Ref8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., March 1994. [Ref9] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, RainbowBridge Communications, Stanford University, March 1994. [Ref10] Ferguson, D., "The OSPF External Attributes LSA", unpublished. [Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, Cascade, April 1995. [Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990. [Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995. Coltun et al [Page 12]
Internet Draft OSPF for IPv6 February 1996 [Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks, December 1995. [Ref15] Deering, S. and R. Hinden, "IP Version 6 Addressing Architecture", RFC 1884, Xerox PARC, Ipsilon Networks, December 1995. [Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" RFC 1885, Digital Equipment Corporation, Xerox PARC, December 1995. [Ref17] Narten, T., E. Nordmark and W. A. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", IBM, Sun Microsystems, work in progress. [Ref18] McCann, J. and S. Deering, "Path MTU Discovery for IP version 6", Digital Equipment Corporation, Xerox PARC, work in progress. [Ref19] Atkinson, R., "IP Authentication Header", RFC 1826, Naval Research Laboratory, August 1995. [Ref20] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, Naval Research Laboratory, August 1995. Coltun et al [Page 13]
Internet Draft OSPF for IPv6 February 1996 A. OSPF data formats This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IPv6 network layer. Before any data formats are described, the details of the OSPF encapsulation are explained. Next the OSPF Options field is described. This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets and in OSPF LSAs. OSPF packet formats are detailed in Section A.3. A description of OSPF LSAs appears in Section A.4. This section describes how IPv6 address prefixes are represented within LSAs, details the standard LSA header, and then provides formats for each of the specific LSA types. A.1 Encapsulation of OSPF packets OSPF runs directly over the IPv6's network layer. OSPF packets are therefore encapsulated solely by IPv6 and local data-link headers. OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes. The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the sizes of OSPF packets sent over virtual links to 576 bytes unless Path MTU Discovery is being performed. The other important features of OSPF's IPv6 encapsulation are: o Use of IPv6 multicast. Some OSPF messages are multicast, when sent over broadcast networks. Two distinct IP multicast addresses are used. Packets sent to these multicast addresses should never be forwarded; they are meant to travel a single hop only. As such, the multicast addresses have been chosen with link-local scope, and packets sent to these addresses should have their IPv6 Hop Limit set to 1. AllSPFRouters This multicast address has been assigned the value FF02::5. Coltun et al [Page 14]
Internet Draft OSPF for IPv6 February 1996 All routers running OSPF should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPF protocol packets are sent to this address during the flooding procedure. AllDRouters This multicast address has been assigned the value FF02::6. Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPF protocol packets are sent to this address during the flooding procedure. o OSPF is IP protocol 89. This number should be inserted in the Next Header field of the enapsulating IPv6 header. o Routing protocol packets are sent with IPv6 Priority field set to 7 (internet control traffic). OSPF protocol packets should be given precedence over regular IPv6 data traffic, in both sending and receiving. Coltun et al [Page 15]
Internet Draft OSPF for IPv6 February 1996 A.2 The Options field The 24-bit OSPF Options field is present in OSPF Hello packets, Database Description packets and certain LSAs (router-LSAs, network-LSAs, inter-area-router-LSAs and link-LSAs). The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism routers of differing capabilities can be mixed within an OSPF routing domain. When used in Hello packets, the Options field allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in Database Description packets a router can choose not to forward certain LSAs to a neighbor because of its reduced functionality. Lastly, listing capabilities in LSAs allows routers to forward data traffic around reduced functionality routers, by excluding them from parts of the routing table calculation. Six bits of the OSPF Options field have been assigned. Each bit is described briefly below. Routers should reset (i.e. clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating LSAs. Conversely, routers encountering unrecognized Option bits in received Hello Packets, Database Description packets or LSAs should ignore the capability and process the packet/LSA normally. 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ | | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ The Options field V6-bit The bit indicates whether the router/link should be included in IPv6 routing calculations. See Section XXXX of this memo. E-bit This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [Ref1]. MC-bit This bit describes whether IP multicast datagrams are forwarded according to the specifications in [Ref7]. Coltun et al [Page 16]
Internet Draft OSPF for IPv6 February 1996 N-bit This bit describes the handling of Type-7 LSAs, as specified in [Ref8]. R-bit This bit (the `Router' bit) indicates whether the originator is an active router. If the router bit is clear routes which transit the advertising node may not be computed. Clearing the router bit would be appropriate for a multi-homed host that wants to participate in routing, but does not want to forward non-locally addressed packets. See Section XXXX of this memo. DC-bit This bit describes the router's handling of demand circuits, as specified in [Ref10]. Coltun et al [Page 17]
Internet Draft OSPF for IPv6 February 1996 A.3 OSPF Packet Formats There are five distinct OSPF packet types. All OSPF packet types begin with a standard 20 byte header. This header is described first. Each packet type is then described in a succeeding section. In these sections each packet's division into fields is displayed, and then the field definitions are enumerated. All OSPF packet types (other than the OSPF Hello packets) deal with lists of LSAs. For example, Link State Update packets implement the flooding of LSAs throughout the OSPF routing domain. The format of LSAs is described in Section A.4. The receive processing of OSPF packets is detailed in Section XXXX. The sending of OSPF packets is explained in Section XXXX. Coltun et al [Page 18]
Internet Draft OSPF for IPv6 February 1996 A.3.1 The OSPF packet header Every OSPF packet starts with a standard 20 byte header. Together with the encapsulating IPv6 headers, the OSPF header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section XXXX of this memo. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | Type | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version # The OSPF version number. This specification documents version 3 of the OSPF protocol. Type The OSPF packet types are as follows. See Sections A.3.2 through A.3.6 for details. Type Description ________________________________ 1 Hello 2 Database Description 3 Link State Request 4 Link State Update 5 Link State Acknowledgment Packet length The length of the OSPF protocol packet in bytes. This length includes the standard OSPF header. Coltun et al [Page 19]
Internet Draft OSPF for IPv6 February 1996 Router ID The Router ID of the packet's source. Area ID A 32 bit number identifying the area that this packet belongs to. All OSPF packets are associated with a single area. Most travel a single hop only. Packets travelling over a virtual link are labelled with the backbone Area ID of 0. Checksum The standard IP checksum of the entire contents of the packet, starting with the OSPF packet header. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. Instance ID Enables multiple instances of OSPF to be run over a single link. Each protocol instance would be assigned a separate Instance ID; the Instance ID has local link significance only. Received packets whose Instance ID is not equal to the receiving interface's Instance ID are discarded. 0 These fields are reserved. They must be 0. Coltun et al [Page 20]
Internet Draft OSPF for IPv6 February 1996 A.3.2 The Hello packet Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello Packets are multicast on those links having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers. All routers connected to a common link must agree on certain parameters (HelloInterval and RouterDeadInterval). These parameters are included in Hello packets, so that differences can inhibit the forming of neighbor relationships. The Hello packet also contains fields used in Designated Router election (Designated Router ID and Backup Designated Router ID), and fields used to detect bi- directionality (the Router IDs of all neighbors whose Hellos have been recently received). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 1 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtr Pri | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | RouterDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Designated Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Interface ID 32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some Coltun et al [Page 21]
Internet Draft OSPF for IPv6 February 1996 implementations it may be possible to use the MIB-II IfIndex. Rtr Pri This router's Router Priority. Used in (Backup) Designated Router election. If set to 0, the router will be ineligible to become (Backup) Designated Router. Options The optional capabilities supported by the router, as documented in Section A.2. HelloInterval The number of seconds between this router's Hello packets. RouterDeadInterval The number of seconds before declaring a silent router down. Designated Router ID The identity of the Designated Router for this network, in the view of the sending router. The Designated Router is identified by its Router ID. Set to 0.0.0.0 if there is no Designated Router. Backup Designated Router ID The identity of the Backup Designated Router for this network, in the view of the sending router. The Backup Designated Router is identified by its IP Router ID. Set to 0.0.0.0 if there is no Backup Designated Router. Neighbor ID The Router IDs of each router from whom valid Hello packets have been seen recently on the network. Recently means in the last RouterDeadInterval seconds. Coltun et al [Page 22]
Internet Draft OSPF for IPv6 February 1996 A.3.3 The Database Description packet Database Description packets are OSPF packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose a poll-response procedure is used. One of the routers is designated to be the master, the other the slave. The master sends Database Description packets (polls) which are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 2 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|I|M|MS Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DD sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- An LSA Header -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | The format of the Database Description packet is very similar to both the Link State Request and Link State Acknowledgment packets. The main part of all three is a list of items, each item describing a piece of the link-state database. The sending of Database Description Packets is documented in Section 10.8 of [Ref1]. The reception of Database Description packets is documented in Section 10.6 of [Ref1]. Coltun et al [Page 23]
Internet Draft OSPF for IPv6 February 1996 I-bit The Init bit. When set to 1, this packet is the first in the sequence of Database Description Packets. M-bit The More bit. When set to 1, it indicates that more Database Description Packets are to follow. MS-bit The Master/Slave bit. When set to 1, it indicates that the router is the master during the Database Exchange process. Otherwise, the router is the slave. Options The optional capabilities supported by the router, as documented in Section A.2. DD sequence number Used to sequence the collection of Database Description Packets. The initial value (indicated by the Init bit being set) should be unique. The DD sequence number then increments until the complete database description has been sent. The rest of the packet consists of a (possibly partial) list of the link-state database's pieces. Each LSA in the database is described by its LSA header. The LSA header is documented in Section A.4.1. It contains all the information required to uniquely identify both the LSA and the LSA's current instance. Coltun et al [Page 24]
Internet Draft OSPF for IPv6 February 1996 A.3.4 The Link State Request packet Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used. A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting. Each instance is defined by its LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request Packet itself. The router may receive even more recent instances in response. The sending of Link State Request packets is documented in Section 10.9 of [Ref1]. The reception of Link State Request packets is documented in Section 10.7 of [Ref1]. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 3 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA, but not its instance. Link State Request packets are understood to be requests for the most recent instance (whatever that might be). Coltun et al [Page 25]
Internet Draft OSPF for IPv6 February 1996 A.3.5 The Link State Update packet Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet. Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always carried by unicast Link State Update packets. For more information on the reliable flooding of LSAs, consult Section XXXX. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 4 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # LSAs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- +-+ | LSAs | +- +-+ | ... | # LSAs The number of LSAs included in this update. The body of the Link State Update packet consists of a list of LSAs. Each LSA begins with a common 20 byte header, described in Section A.4.2. Detailed formats of the different types of LSAs are described in Section A.4. Coltun et al [Page 26]
Internet Draft OSPF for IPv6 February 1996 A.3.6 The Link State Acknowledgment packet Link State Acknowledgment Packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. Multiple LSAs can be acknowledged in a single Link State Acknowledgment packet. Depending on the state of the sending interface and the sender of the corresponding Link State Update packet, a Link State Acknowledgment packet is sent either to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast. The sending of Link State Acknowledgement packets is documented in Section 13.5 of [Ref1]. The reception of Link State Acknowledgement packets is documented in Section 13.7 of [Ref1]. The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of LSA headers. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 5 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- An LSA Header -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Each acknowledged LSA is described by its LSA header. The LSA header is documented in Section A.4.2. It contains all the information required to uniquely identify both the LSA and the LSA's Coltun et al [Page 27]
Internet Draft OSPF for IPv6 February 1996 current instance. Coltun et al [Page 28]
Internet Draft OSPF for IPv6 February 1996 A.4 LSA formats This memo defines seven distinct types of LSAs. Each LSA begins with a standard 20 byte LSA header. This header is explained in Section A.4.2. Succeeding sections then diagram the separate LSA types. Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. A network-LSA is advertised for each link by its Designated Router. A router's link-local addresses are advertised to its neighbors in link-LSAs. IPv6 prefixes are advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs and AS-external-LSAs. Location of specific routers can be advertised across area boundaries in inter-area-router-LSAs. All LSAs are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of LSAs. (See Section XXXX for more information concerning the flooding algorithm). This collection of LSAs is called the link- state database. From the link state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11 of [Ref1]). For the details of the routing table build process, see Section XXXX. Coltun et al [Page 29]
Internet Draft OSPF for IPv6 February 1996 A.4.1 IPv6 Prefix Representation IPv6 address prefixes are always represented by a PrefixLength, representing the length in bits of the significant part of the prefix (value 0 - 128 inclusive), an 8-bit PrefixOptions field, and then a variable amount of prefix information. The prefix information is always an even multiple of 32-bit words long, and is padded with zero bits to the next 32-bit word boundary. The length of the prefix information, in 32-bit words, is therefore ((PrefixLength + 31) / 32). The default route is represented by a prefix of length 0. Coltun et al [Page 30]
Internet Draft OSPF for IPv6 February 1996 A.4.1.1 Prefix Options Each prefix is advertised along with an 8-bit field of capabilities. These serve as input to the various routing calculations, allowing, for example, certain prefixes to be ignored in some cases, or to be marked as not readvertisable in others. 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | | | | | P|MC|LA|NU| +--+--+--+--+--+--+--+--+ The Prefix Options field NU-bit The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations, otherwise it should be included. LA-bit The "local address" capability bit. If set, the prefix is actually an IPv6 interface address of the advertising router. MC-bit The "multicast" capability bit. If set, the prefix should be included in IPv6 multicast routing calculations, otherwise it should be excluded. P-bit The "propagate" bit. Set on NSSA area prefixes that should be readvertised at the NSSA area border. Coltun et al [Page 31]
Internet Draft OSPF for IPv6 February 1996 A.4.2 The LSA header All LSAs begin with a common 20 byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number and LS checksum fields that are also contained in the LSA header. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS age The time in seconds since the LSA was originated. LS type The type of the LSA. Each LSA type has a separate advertisement format. See Section A.4.2.1 for a detailed description of LS type. Link State ID Together with LS type and Advertising Router, uniquely identifies the LSA in the link-state database. Advertising Router The Router ID of the router that originated the LSA. For example, in network-LSAs this field is equal to the Router ID of the network's Designated Router. LS sequence number Detects old or duplicate LSAs. Successive instances of an LSA are given successive LS sequence numbers. See Section 12.1.6 in [Ref1] for more details. Coltun et al [Page 32]
Internet Draft OSPF for IPv6 February 1996 LS checksum The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the LS age field. See Section 12.1.7 in [Ref1] for more details. length The length in bytes of the LSA. This includes the 20 byte LSA header. Coltun et al [Page 33]
Internet Draft OSPF for IPv6 February 1996 A.4.2.1 LS type The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. The format of the LS type is as follows: 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |U |S2|S1| LSA Function Code | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The U bit indicates how the LSA should be handled by a router which does not recognize its function code. Its values are: U-bit LSA Handling ____________________________________________________________ 0 Store and flood the LSA, as if type understood 1 Treat the LSA as if it had link-local flooding scope The S1 and S2 bits indicate the flooding scope of the LSA. The values are: S2 S1 Flooding Scope _______________________________________________________________________ 0 0 Link-Local Scoping. Flooded only on link it is originated on. 0 1 Area Scoping. Flooded to all routers in the originating area 1 0 AS Scoping. Flooded to all routers in the AS 1 1 Reserved The LSA function codes are defined as follows. The origination and processing of these LSA function codes are defined elsewhere in this memo, except for the group-membership-LSA (see [Ref7]) and the Type-7-LSA (see [Ref8]). Each LSA function code also implies a specific setting for the U, S1 and S2 bits, as shown below. Coltun et al [Page 34]
Internet Draft OSPF for IPv6 February 1996 LSA function code LS Type Description ___________________________________________________ 1 0x2001 Router-LSA 2 0x2002 Network-LSA 3 0x2003 Inter-Area-Prefix-LSA 4 0x2004 Inter-Area-Router-LSA 5 0x4005 AS-External-LSA 6 0x2006 Group-membership-LSA 7 0x2007 Type-7-LSA 8 0x0008 Link-LSA 9 0x2009 Intra-Area-Prefix-LSA Coltun et al [Page 35]
Internet Draft OSPF for IPv6 February 1996 A.4.3 Router-LSAs Router-LSAs have LS type equal to 0x2001. Each router in an area originates one or more router-LSAs. The complete collection of router-LSAs originated by the router describe the state and cost of the router's interfaces to the area. For details concerning the construction of router-LSAs, see Section XXXX. Router-LSAs are flooded throughout a single area only. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | A single router may originate one or more Router LSAs, distinguished by their Link-State IDs (which are chosen arbitrarily by the Coltun et al [Page 36]
Internet Draft OSPF for IPv6 February 1996 originating router). The Options field and V, E and B bits should be the same in all Router LSAs from a single originator. However, in the case of a mismatch the values in the LSA with the lowest Link State ID take precedence. When more than one Router LSA is received from a single router, the links are processed as if concatenated into a single LSA. bit V When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as Transit area (V is for virtual link endpoint). bit E When set, the router is an AS boundary router (E is for external). bit B When set, the router is an area border router (B is for border). Options The optional capabilities supported by the router, as documented in Section A.2. The following fields are used to describe each router interface. The Type field indicates the kind of interface being described. It may be an interface to a transit network, a point-to-point connection to another router or a virtual link. The values of all the other fields describing a router interface depend on the interface's Type field. Type The kind of interface being described. One of the following: Type Description __________________________________________________ 1 Point-to-point connection to another router 2 Connection to a transit network 3 Reserved 4 Virtual link Coltun et al [Page 37]
Internet Draft OSPF for IPv6 February 1996 Metric The cost of using this router interface, for outbound traffic. Interface ID The Interface ID assigned to the interface being described. See Sections XXXX and C.3. Neighbor Interface ID The Interface ID the neighbor router (or the attached link's Designated Router, for Type 2 interfaces) has been advertising in hello packets sent on the atached link. n Neighbor Router ID The Router ID the neighbor router (or the attached link's Designated Router, for Type 2 interfaces). For Type 2 links, the combination of Neighbor Interface ID and Neighbor Router ID allows the network-LSA for the attached link to be found in the link-state database. Coltun et al [Page 38]
Internet Draft OSPF for IPv6 February 1996 A.4.4 Network-LSAs Network-LSAs have LS type equal to 0x2002. A network-LSA is originated for each broadcast and NBMA link in the area which supports two or more routers. The network-LSA is originated by the link's Designated Router. The LSA describes all routers attached to the link, including the Designated Router itself. The LSA's Link State ID field is set to the Interface ID that the Designated Router has been advertising in Hello packets on the link. The distance from the network to all attached routers is zero. This is why the metric fields need not be specified in the network-LSA. For details concerning the construction of network-LSAs, see Section XXXX. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attached Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Attached Router The Router IDs of each of the routers attached to the link. Actually, only those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the LSA header's length field. Coltun et al [Page 39]
Internet Draft OSPF for IPv6 February 1996 A.4.5 Inter-Area-Prefix-LSAs Inter-Area-Prefix-LSAs have LS type equal to 0x2003. These LSAs are originated by area border routers, and describe routes to IPv6 address prefixes that belong to other areas. A separate Inter-Area- Prefix-LSA is originated for each IPv6 address prefix. For details concerning the construction of Inter-Area-Prefix-LSAs, see Section XXXX. For stub areas, Inter-Area-Prefix-LSAs can also be used to describe a (per-area) default route. Default summary routes are used in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the Inter-Area-Prefix-LSA's PrefixLength is set to 0. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Metric The cost of this route. Expressed in the same units as the interface costs in the router-LSAs. When the Inter-Area-Prefix- LSA is describing a route to a range of addresses (see Section C.2) the cost is set to the maximum cost to any reachable component of the address range. PrefixLength, PrefixOptions and Address Prefix Representation of the IPv6 address prefix, as described in Section A.4.1. Coltun et al [Page 40]
Internet Draft OSPF for IPv6 February 1996 A.4.6 Inter-Area-Router-LSAs Inter-Area-Router-LSAs have LS type equal to 0x2004. These LSAs are originated by area border routers, and describe routes to routers in other areas. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 in [Ref1].) Each LSA describes a route to a single router. For details concerning the construction of Inter-Area-Router-LSAs, see Section XXXX. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Options The optional capabilities supported by the router, as documented in Section A.2. Metric The cost of this route. Expressed in the same units as the interface costs in the router-LSAs. Destination Router ID The Router ID of the router being described by the LSA. Coltun et al [Page 41]
Internet Draft OSPF for IPv6 February 1996 A.4.7 AS-external-LSAs AS-external-LSAs have LS type equal to 0x2005. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. Each LSA describes a route to a single IPv6 address prefix. For details concerning the construction of AS- external-LSAs, see Section XXXX. AS-external-LSAs can be used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the AS-external-LSA's PrefixLength is set to 0. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E|F| Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | Referenced LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Forwarding Address (Optional) -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bit E The type of external metric. If bit E is set, the metric Coltun et al [Page 42]
Internet Draft OSPF for IPv6 February 1996 specified is a Type 2 external metric. This means the metric is considered larger than any intra-AS path. If bit E is zero, the specified metric is a Type 1 external metric. This means that it is expressed in the same units as the link state metric (i.e., the same units as interface cost). bit F If set, a forwarding address has been included in the LSA. Metric The cost of this route. Interpretation depends on the external type indication (bit E above). PrefixLength, PrefixOptions and Address Prefix Representation of the IPv6 address prefix, as described in Section A.4.1. Referenced LS type If non-zero, an LSA with this LS type is to be associated with this LSA (see Referenced Link State ID below). Forwarding address A fully qualified IPv6 address (128 bits). Included in the LSA if and only if bit F has been set. If included, Data traffic for the advertised destination and TOS will be forwarded to this address. Must not be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0). Referenced Link State ID Included if and only if Reference LS Type is non-zero. If included, additional information concerning the advertised external route can be found in the LSA having LS type equal to "Referenced LS Type", Link State ID equal to "Referenced Link State ID" and Advertising Router the same as that specified in the AS-external-LSA's link state header. This additional information is not used by the OSPF protocol itself. It may be used to communicate information between AS boundary routers; the precise nature of such information is outside the scope of this specification. If Forwarding address and Referenced Link State ID are both included in the AS-external-LSA, Forwarding Address always comes first. Coltun et al [Page 43]
Internet Draft OSPF for IPv6 February 1996 A.4.8 Link-LSAs Link-LSAs have LS type equal to 0x0008. A router originates a separate Link-LSA for each link it is attached to. These LSAs have local-link flooding scope; they are never flooded beyond the link that they are associated with. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link and 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link and 3) they allow the router to assert a collection of Options bits to associate with the Network-LSA that will be originated for the link. A link-LSA's Link State ID is set equal to the originating router's Interface ID on the link. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|0| 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtr Pri | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Link-local Interface Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # prefixes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Coltun et al [Page 44]
Internet Draft OSPF for IPv6 February 1996 | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rtr Pri The Router Priority of the interface attaching the originating router to the link. Options The set of Options bits that the router would like set in the Network-LSA that will be originated for the link. Link-local Interface Address The originating router's link-local interface address on the link. # prefixes The number of IPv6 address prefixes contained in the LSA. The rest of the link-LSA contains a list of IPv6 prefixes to be associated with the link. PrefixLength, PrefixOptions and Address Prefix Representation of an IPv6 address prefix, as described in Section A.4.1. Coltun et al [Page 45]
Internet Draft OSPF for IPv6 February 1996 A.4.9 Intra-Area-Prefix-LSAs Intra-Area-Prefix-LSAs have LS type equal to 0x2009. Intra-Area- Prefix-LSAs allow a router to associate one or more IPv6 address prefixes with a router (itself) or a transit link (one of the originating router's attached links). These prefixes are then processed as "stub links" during the OSPF intra-area routing calculation (see Section XXXX). A router can originate multiple Intra-Area-Prefix-LSAs for each router or transit network; each such LSA is distinguished by its Link State ID. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # prefixes | Referenced LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # prefixes The number of IPv6 address prefixes contained in the LSA. Coltun et al [Page 46]
Internet Draft OSPF for IPv6 February 1996 Referenced LS type, Referenced Link State ID and Referenced Advertising Router" Identifies the router-LSA or network-LSA with which the IPv6 address prefixes should be associated. If Referenced LS type is 1, the prefixes are associated with a router-LSA, Referenced Link State ID should be 0 and Referenced Advertising Router should be the originating router's Router ID. If Referenced LS type is 2, the prefixes are associated with a network-LSA, Referenced Link State ID should be the Interface ID of the link's Designated Router and Referenced Advertising Router should be the Designated Router's Router ID. The rest of the Intra-Area-Prefix-LSA contains a list of IPv6 prefixes to be associated with the router or transit link, together with the cost of each prefix. PrefixLength, PrefixOptions and Address Prefix Representation of an IPv6 address prefix, as described in Section A.4.1. Metric The cost of this prefix. Expressed in the same units as the interface costs in the router-LSAs. Coltun et al [Page 47]
Internet Draft OSPF for IPv6 February 1996 B. Architectural Constants Architectural coonstants for the OSPF protocol are defined in Appendix C of [Ref1]. The only difference for OSPF for IPv6 is that DefaultDestination is encoded as a prefix of length 0 (see Section A.4.1). C. Configurable Constants The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters. Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters, and all routers attached to a network must agree on that network's HelloInterval and RouterDeadInterval. Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable. C.1 Global parameters In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below. Router ID This is a 32-bit number that uniquely identifies the router in the Autonomous System. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting in order to change its Router ID, the router should flush its self-originated LSAs from the routing domain (see Section 14.1 of [Ref1]), or they will persist for up to MaxAge minutes. C.2 Area parameters All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of routing protocol and data Coltun et al [Page 48]
Internet Draft OSPF for IPv6 February 1996 traffic. The following items must be configured for an area: Area ID This is a 32-bit number that identifies the area. The Area ID of 0 is reserved for the backbone. List of address ranges Address ranges control the advertisement of routes across area boundaries. Each address range consists of the following items: [IPv6 prefix, prefix length] Describes the collection of IPv6 addresses contained in the address range. Status Set to either Advertise or DoNotAdvertise. Routing information is condensed at area boundaries. External to the area, at most a single route is advertised (via a inter-area-prefix-LSA) for each address range. The route is advertised if and only if the address range's Status is set to Advertise. Unadvertised ranges allow the existence of certain networks to be intentionally hidden from other areas. Status is set to Advertise by default. ExternalRoutingCapability Whether AS-external-LSAs will be flooded into/throughout the area. If AS-external-LSAs are excluded from the area, the area is called a "stub". Internal to stub areas, routing to external destinations will be based solely on a default inter-area route. The backbone cannot be configured as a stub area. Also, virtual links cannot be configured through stub areas. For more information, see Section 3.6 of [Ref1]. StubDefaultCost If the area has been configured as a stub area, and the router itself is an area border router, then the StubDefaultCost indicates the cost of the default inter- area-prefix-LSA that the router should advertise into the area. See Section XXXX for more information. C.3 Router interface parameters Some of the configurable router interface parameters (such as Area ID, HelloInterval and RouterDeadInterval) actually imply properties of the attached links, and therefore must be Coltun et al [Page 49]
Internet Draft OSPF for IPv6 February 1996 consistent across all the routers attached to that link. The parameters that must be configured for a router interface are: IPv6 link-local address The IPv6 link-local address associated with this interface. May be learned through auto-configuration. Area ID The OSPF area to which the attached link belongs. Instance ID The OSPF protocol instance associated with this OSPF interface. Defaults to 0. Interface ID 32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some implementations it may be possible to use the MIB-II IfIndex. IPv6 prefixes The list of IPv6 prefixes to associate with the link. These will be advertised in intra-area-prefix-LSAs. Interface output cost(s) The cost of sending a packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router's router-LSA. The interface output cost must always be greater than 0. RxmtInterval The number of seconds between LSA retransmissions, for adjacencies belonging to this interface. Also used when retransmitting Database Description and Link State Request Packets. This should be well over the expected round-trip delay between any two routers on the attached link. The setting of this value should be conservative or needless retransmissions will result. Sample value for a local area network: 5 seconds. InfTransDelay The estimated number of seconds it takes to transmit a Link State Update Packet over this interface. LSAs contained in the update packet must have their age incremented by this amount before transmission. This value should take into account the transmission and propagation delays of the interface. It must be greater than 0. Sample value for a Coltun et al [Page 50]
Internet Draft OSPF for IPv6 February 1996 local area network: 1 second. Router Priority An 8-bit unsigned integer. When two routers attached to a network both attempt to become Designated Router, the one with the highest Router Priority takes precedence. If there is still a tie, the router with the highest Router ID takes precedence. A router whose Router Priority is set to 0 is ineligible to become Designated Router on the attached link. Router Priority is only configured for interfaces to broadcast and NBMA networks. HelloInterval The length of time, in seconds, between the Hello Packets that the router sends on the interface. This value is advertised in the router's Hello Packets. It must be the same for all routers attached to a common link. The smaller the HelloInterval, the faster topological changes will be detected; however, more OSPF routing protocol traffic will ensue. Sample value for a X.25 PDN: 30 seconds. Sample value for a local area network (LAN): 10 seconds. RouterDeadInterval After ceasing to hear a router's Hello Packets, the number of seconds before its neighbors declare the router down. This is also advertised in the router's Hello Packets in their RouterDeadInterval field. This should be some multiple of the HelloInterval (say 4). This value again must be the same for all routers attached to a common link. C.4 Virtual link parameters Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as an unnumbered point-to-point link in the graph for the backbone. The virtual link must be configured in both of the area border routers. A virtual link appears in router-LSAs (for the backbone) as if it were a separate router interface to the backbone. As such, it has most of the parameters associated with a router interface (see Section C.3). Virtual links do not have link-local addresses, but instead use one of the router's global-scope or site-local IPv6 addresses as the IP source in OSPF protocol packets it sends along the virtual link. Router Priority is not used on virtual links. Interface output cost is not configured on virtual links, but is dynamically set to be the cost of the Coltun et al [Page 51]
Internet Draft OSPF for IPv6 February 1996 intra-area path between the two endpoint routers. The parameter RxmtInterval must be configured, and should be well over the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too large. A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint, and the (non-backbone) area through which the virtual link runs (referred to as the virtual link's Transit area). Virtual links cannot be configured through stub areas. C.5 NBMA network parameters OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA, which lists all routers attached to the NBMA network. However, due to the lack of broadcast capabilities, it may be necessary to use configuration parameters in the Designated Router selection. These parameters will only need to be configured in those routers that are themselves eligible to become Designated Router (i.e., those router's whose Router Priority for the network is non-zero), and then only if no automatic procedure for discovering neighbors exists: List of all other attached routers The list of all other routers attached to the NBMA network. Each router is configured with its Router ID and IPv6 link- local address on the network. Also, for each router listed, that router's eligibility to become Designated Router must be defined. When an interface to a NBMA network comes up, the router sends Hello Packets only to those neighbors eligible to become Designated Router, until the identity of the Designated Router is discovered. PollInterval If a neighboring router has become inactive (Hello Packets have not been seen for RouterDeadInterval seconds), it may still be necessary to send Hello Packets to the dead neighbor. These Hello Packets will be sent at the reduced rate PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network: 2 minutes. Coltun et al [Page 52]
Internet Draft OSPF for IPv6 February 1996 C.6 Point-to-MultiPoint network parameters On Point-to-MultiPoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the Point-to-MultiPoint network. Each neighbor is configured with its Router ID and IPv6 link-local address on the network. Designated Routers are not elected on Point-to-MultiPoint networks, so the Designated Router eligibility of configured neighbors is undefined. C.7 Host route parameters Host routes are advertised in intra-area-prefix-LSAs as fully qualified IPv6 prefixes (i.e., prefix length set equal to 128 bits). They indicate either router interfaces to point-to-point networks, looped router interfaces, or IPv6 hosts that are directly connected to the router (e.g., via a PPP connection). For each host directly connected to the router, the following items must be configured: Host IPv6 address The IPv6 address of the host. Cost of link to host The cost of sending a packet to the host, in terms of the link state metric. However, since the host probably has only a single connection to the internet, the actual configured cost(s) in many cases is unimportant (i.e., will have no effect on routing). Area ID The OSPF area to which the host belongs. Coltun et al [Page 53]
Internet Draft OSPF for IPv6 February 1996 Security Considerations When running over IPv6, OSPF relies on the IP Authentication Header (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref120]) to ensure integrity and authentication/confidentiality of routing exchanges. Authors Addresses Rob Coltun FORE Systems Phone: (301) 571-2521 email: rcoltun@fore.com Dennis Ferguson Ipsilon Networks dennis@Ipsilon.COM John Moy Cascade Communications Corp. 5 Carlisle Road Westford, MA 01886 Phone: 508-952-1367 Fax: 508-692-9214 Email: jmoy@casc.com This document expires in August 1996. Coltun et al [Page 54]
