Internet Draft OSPFv6 December 1995 Expiration Date: June 1996 FORE Systems File name: draft-coltun-ospf-ospfv6-00.txt OSPF Version 2 For IP Version 6 Rob Coltun FORE Systems (301) 571-2521 rcoltun@fore.com Status Of This Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Coltun Expires June 1996 [Page 1] Internet Draft OSPFv6 December 1995 Table Of Contents 1.0 Abstract ................................................. 4 2.0 Overview ................................................. 4 2.1 Organization Of This Document ............................ 4 2.2 Acknowledgments .......................................... 4 3.0 OSPFv4 To OSPFv6 Diffs ................................... 5 3.1 Features That Haven't Been Modified ...................... 5 3.2 Features That Have Been Removed .......................... 6 3.2.1 TOS-Based Routing ...................................... 6 3.3 Modifications And Extensions ............................. 6 3.3.1 Extensions To Address And ID Fields .................... 6 3.3.2 Semantics Of The Network Mask Field .................... 6 3.3.3 External LSA Forwarding Address And Route Tag .......... 7 3.3.4 Protocol Packet Processing Modifications ............... 7 3.4 Additions To OSPFv6 ...................................... 8 3.4.1 Support Of The Opaque LSA .............................. 8 3.4.2 Instance ID ............................................ 8 4.0 Overview Of OSPFv6 Packet Formats ........................ 8 4.1 The OSPF Packet Header ................................... 9 4.2 The Hello Packet ......................................... 9 4.3 The Link-State Advertisement Header ...................... 10 4.4 The Database Description Packet .......................... 10 4.5 The Link-State Request Packet ............................ 10 4.6 The Link-State Acknowledgment Packet ..................... 11 4.7 The Link-State Update Packet ............................. 11 4.7.1 The Router LSA ......................................... 12 4.7.2 The Network LSA ........................................ 12 4.7.3 Summary LSA ............................................ 12 4.7.4 The AS External LSA .................................... 12 5.0 Protocol Packet Processing ............................... 14 5.1 Sending Protocol Packets ................................. 14 5.2 Receiving Protocol Packets ............................... 16 6.0 Opaque LSAs .............................................. 19 6.1 Modifications To The Neighbor State Machine .............. 20 6.2 Modifications To The Flooding Procedures ................. 20 7.0 AS External Routes ....................................... 22 7.1 Origination Of AS External Reference Opaque LSA .......... 22 7.2 Calculating AS External Routes ........................... 22 8.0 References ............................................... 24 Appendix A: OSPFv6 Data Formats .............................. 25 A.1 Encapsulation Of OSPFv6 Packets .......................... 25 A.2 The Options Field ........................................ 27 A.3 OSPFv6 Packet Formats .................................... 29 A.3.1 The OSPFv6 Packet Header ............................... 29 A.3.2 The Hello Packet ....................................... 32 A.3.3 The Database Description Packet ........................ 35 A.3.4 The Link-State Request Packet .......................... 37 A.3.5 The Link-State Update Packet ........................... 40 A.3.6 The Link-State Acknowledgment Packet ................... 41 A.4 Link-State Advertisement (LSA) Formats ................... 43 A.4.1 The Link-State Advertisement Header .................... 43 A.4.2 Router LSA ............................................. 46 A.4.3 Network LSA ............................................ 49 Coltun Expires June 1996 [Page 2] Internet Draft OSPFv6 December 1995 A.4.4 Summary LSA ............................................ 51 A.4.5 AS External LSA ........................................ 53 A.4.6 Opaque LSA ............................................. 55 A.4.6.1 Link-Local Opaque LSA ................................ 57 A.4.6.2 AS External Reference Opaque LSA ..................... 59 Appendix B: Architectural Constants .......................... 61 Appendix C: Configurable Constants ........................... 62 C.1 Global Parameters ........................................ 62 Coltun Expires June 1996 [Page 3] Internet Draft OSPFv6 December 1995 1.0 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. The packet formats have been extended to support IPv6 addressing as IPv6 increases the IP address size from 32 bits to 128 bits. Additionally, an Instance ID (i.e., process identifier) has been added to the OSPF packet header to facilitate routers runing more than one OSPFv6 instance. 2.0 Overview Over the last few years the OSPF routing protocol [OSPF] has been widely deployed throughout the Internet. As a result of this deploy- ment OSPF has been cleaned up, tuned up and extended as new require- ments have emerged. We now have a large operational and implementa- tion knowledge base. Our goal is to utilize this existing experience base and extend OSPF to support IPv6 [IPV6], which we will refer to as OSPFv6. The OSPF area architecture and its fundamental mechanisms (flooding, DR election, SPF calculations, etc.) remain unchanged. OSPF's options (on-demand circuits support, NSSA areas, multicast extensions, point- to-multipoint, etc.) are directly applicable. It is assumed that the reader is familiar with the OSPF protocol as specified in [OSPF]. The basic change to OSPF to support IPv6 is to extend the net/subnet address, link-state ID, router ID and area ID fields from 32 to 128 bits. We change the syntax of the network mask from an explicit mask to an integer which represents the number of bits in the mask. There- fore when referring to [OSPF], addresses and network masks expressed as a 32-bit "dotted quads" (e.g., 128.185.1.0) should be thought of as IPv6 address in the form expressed in the IPv6 address architecture document [IPV6ADDR] (e.g., FEDC:BA98:7654:3210:FEDC:BA98:7654:3210). 2.1 Organization Of This Document This document first lists the differences between OSPF for IPv4 (OSPFv4) and OSPFv6, followed by the details of these changes includ- ing a description of the packet formats which have been extended to support IPv6. Following that are the mechanisms needed to support the addition of an instance ID in the packet header. Finally we discuss the modifications to the AS external LSA processing and AS External Opaque LSA origination (which is used in conjunction with AS external LSAs). Appendix A gives the packet formats. 2.2 Acknowledgments The author would like to thank Fred Baker, Jim Bound, John Moy and the rest of the OSPF Working Group for the ideas and support they have Coltun Expires June 1996 [Page 4] Internet Draft OSPFv6 December 1995 given to this project. 3.0 OSPFv4 To OSPFv6 Diffs 3.1 Features That Haven't Been Modified The fundamental concept of (sub)networks, CIDR style address and gen- eral routing architecture of IPv6 [IPV6] is the same as those of IPv4. Therefore the mechanisms of OSPF remain unchanged including: o IP subnetting support o The representation of routers and networks o The representation of non-broadcast networks o The link-state database organization o The link-state database exchange mechanisms o The link-state database flooding mechanisms o Neighbor and interface state machines o The (Backup) Designated Router Election Algorithms o Building the shortest-path tree o Support for equal-cost multipath o The splitting of an AS into Areas o Supporting stub areas o The backbone of the Autonomous System o Inter-area routing o The use of external routing information (AS external routes) All of OSPF optional capabilities (on-demand circuits support, NSSA areas, multicast extensions, point-to-multipoint, etc.) are directly applicable to OSPFv6 (with the appropriate IPv6 address extensions). In fact, the version number for OSPFv6 remains as version 2 as this document is viewed to be an extension of OSPFv4 with [OSPF] remaining the base document. Coltun Expires June 1996 [Page 5] Internet Draft OSPFv6 December 1995 3.2 Features That Have Been Removed 3.2.1 TOS-Based Routing The semantics of IPv4 TOS have not been moved forward to IPv6; IPv6 has priority and flow identifiers. Priority gives the IPv6 forwarding engine a hint as to how to queue the packet for processing but does not necessarily represent an independent routing path. 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. In the future the IPv6 Flow Label may be a associated with a non-default route which may turn out to be loosely related to IPv4 TOS, but the Flow Label concept is still experimental and subject to change as the requirements for flow support in the Internet become clearer. Along with the fact that TOS has rarely been used in OSPFv4, OSPFv6 does not support TOS as defined in OSPFv4. 3.3 Modifications And Extensions One of the the fundamental motivations for IPv6 was to increase the IP address size from 32 bits to 128 bits so that IP can support more lev- els of the addressing hierarchy and so that it can address a much greater number of nodes. The majority of the changes were made to accommodate the IPv6 expanded address space while maintaining the phi- losophy of 32-bit aligned fixed-length fields. (Needless to say the routing table must be modified to handle 128-bit network addresses). 3.3.1 Extensions To Address And ID Fields To support IPv6 we extend the (sub)network address, link-state ID, router ID and area ID fields from 32 to 128 bits. An overview of these changes and their effect on database size and fragmentation is given in Section 4.0 entitled "Overview Of OSPFv6 Packet Formats". The packet formats are given in Appendix A. 3.3.2 Semantics Of The Network Mask Field The semantics of the network mask has been changed from an explicit mask to an integer which expresses the number of bits in the network mask (the field is now called "Network Mask Length"). At the time that the original OSPF spec was written, non-contiguous masks were legal. This has since changed and IPv4 and IPv6 allows contiguous masks only. Since the network mask may be up to 128 bits, link-state database memory resources can be saved by representing the mask as the number of bits in the network mask. In the case of the link-data field in the Router LSA the semantics is type specific so that the 128-bits may be an IPv6 address or a network mask length. When it is the network mask length, the first 32 bits of the 128-bit field is treated as an integer which expresses the number of bits in the Coltun Expires June 1996 [Page 6] Internet Draft OSPFv6 December 1995 network mask. 3.3.3 External LSA Forwarding Address And Route Tag OSPFv6 AS External LSAs do not include the forwarding address or the external route tag. Instead, OSPFv6 external LSAs include a 32-bit Opaque LSA Reference field. The reason for this is as follows. In OSPFv4 the Route Tag was not used by the OSPF protocol itself; it was used to communicate information between AS boundary routers. In [BGPOSPF] the route tag is divided into two parts or kept as locally defined information. When it is divided into two parts the upper 16 bits denotes origin information (indications whether the routing information was originated via an IGP, or some other means) and an arbitrary tag. The lower 16 bits are used to communicate an auto- nomous system number. Since CIDR-style addresses [CIDR] are used in IPv6, it is unlikely that a separate address space will be used for IPv6 domains as they are for IPv4's Autonomous System numbers. Instead it is likely that a prefix will be used to represent a domain as it does in IDRP [IDRP]. For the tag to continue to have the same function as in OSPFv4 we would need to include the domain identifier (which is a prefix of a 128-bit address), a length field for the domain identifier, an arbitrary tag and origin information. This information would take up 20 octets. Additionally the forwarding address would have to be extended to 128 bits (another 16 octets). Within an OSPF system, there are relatively few number of AS boundary routers and anywhere from a single default route to tens of thousands of AS external routes injected into the OSPF system. That is a pair will most likely be repeated in a number of External LSAs. If the External Tag were to be extended to include domain, and origin information and the forwarding address were extended to a 128-bit address the External LSA would incur another 36 octets of overhead. When this is combined with the already extended link-state ID and router ID fields the external LSA would be 88-octets much of which is redundant information resulting in unnecessary memory overhead. OSPFv6 introduces a new type of LSA which carries the forwarding address, domain and origin information. See Section A.4.6.2 ("AS External Reference Opaque LSA") for a description of the packet for- mat. This LSA is referenced by the AS External LSA so as to reduce the link-state database overhead. 3.3.4 Protocol Packet Processing Modifications Protocol packet processing has been modified to include the Instance ID (see Section 3.4.2 below). Also, because there is no checksum in the IPv6 header, these sections have been removed. See Section 5.0 ("Protocol Packet Processing") for a description of the OSPFv6 proto- col packet processing. Coltun Expires June 1996 [Page 7] Internet Draft OSPFv6 December 1995 3.4 Additions To OSPFv6 The following items are not part of OSPF but are part of OSPFv6. 3.4.1 Support Of The Opaque LSA The Opaque LSA is need by OSPFv6 as a replacement for OSPFv4's exter- nal LSA's forwarding address and route tag as explained in section 3.3.3 above. To support distribution of the Opaque LSA, modifications were made to the neighbor state machine and to the flooding pro- cedures. See Section 6 of this document for the details of these modifications. 3.4.2 Instance ID OSPFv6 introduces an Instance ID which is used when multiple OSPFv6 instances (or processes) are used. The Instance ID is used both by network management to identify the particular instance to be managed and by the OSPFv6 send and receive functions to identify packet's tar- get OSPFv6 instance. As an example, multiple Instance IDs may be used by a network service provider when the provider participates in a subscriber's IGP (which happens to be OSPF). The provider would therefore need to support several OSPFv6 instances within the same router. Multiple OSPF instances allows the router to have logically partitioned OSPF for reasons of management and policy enforcement. See section 5 of this document for the details of the modifications to the protocol packet processing needed to support the Instance ID. 4.0 Overview Of OSPFv6 Packet Formats The result of extending the IP address to 128 bits is an increase in the size of several of the packet formats for OSPFv6. To support IPv6 we extend the (sub)network address, link-state ID, router ID and area ID fields in the OSPF packet formats from 32 to 128 bits. Addition- ally we change the semantics of the network mask from an explicit mask to be the number of bits (length) of the network mask. The major impact of increasing the lengths of several of the fields is on the link-state database's memory utilization. For larger networks there may be some impact on IP fragmentation of OSPFv6 packets. The OSPF protocol has mechanisms which allows an implementation to manage the contents and size of the OSPF packets. That is, database description, link-state request, link-state update and link-state ack- nowledgement packets all include lists of entries so that an implemen- tation can optimize the size of each of these packets. Most OSPF packets travel a single hop. Hello, database description, link-state request, link-state update and link-state acknowledgement packets are sent on a single interface. At each router, link-state update packets are disassembled into their constituent link-state Coltun Expires June 1996 [Page 8] Internet Draft OSPFv6 December 1995 advertisements which may be then flooded as part of a link-state update packet originated by the receiving router. Since the MTU for the media type associated with the interface is known (except in the case of virtual interfaces), the packets can be optimized for the interface's MTU. In the case of virtual links, the path between virtual neighbors is dynamically discovered so the packets may need to be fragmented by the IP layer along the way. But unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by the routers along a packet's delivery path. Needless to say that OSPF would break if it did not handle the MTU correctly. It is reasonable to assume that for the OSPFv6 packets traversing a virtual link that either 1) an MTU of 576 octets is assumed by OSPF and used by the IP layer or 2) the "Path MTU Discovery for IP version 6" [PMTU] protocol is run by the IP layer on area border routers which are end points of a virtual link. The following describes the modifications to the OSPF packet formats to support IPv6 and the effects of extending the net/subnet address, link-state ID, router ID and area ID fields from 32 to 128 bits. All of the packets formats are described in detail in Appendix A. 4.1 The OSPF Packet Header Every OSPF packet starts with a common header. This header contains all the necessary information to determine whether the packet should be accepted for further processing. The packet format has been modi- fied so that the Router ID field and the Area ID field are increased to 128 bits. The effect of this is that the packet header is now 48 octets and was 24 octets in OSPFv4. This extension contributes very little to additional memory overhead of the implementation (as the packet headers are not usually maintained in the database) and when added to the extensions of the other OSPF packet formats this exten- sion is a minor contributor to the need for IP fragmentation. 4.2 The Hello Packet OSPF's Hello Protocol is responsible for establishing and maintaining neighbor relationships. It also ensures that communication between neighbors is bidirectional. Hello packets are sent periodically out all router interfaces and include a list of the Router IDs of each router from whom valid Hello packets have been seen recently on the network. Bidirectional communication is indicated when the router sees itself listed in the neighbor's Hello Packet. On multi-access networks, the Hello Protocol elects a Designated Router for the net- work. The effect of extending the Area and Router IDs to 128 bits in the Hello Packet is that the Hello Header is now 88 octets. Additionally, each advertised neighbor (the Router ID) on the network is 16 octets Coltun Expires June 1996 [Page 9] Internet Draft OSPFv6 December 1995 so that at around 90 neighbors the Hello packet would be larger than an Ethernet MTU. Although for most networks this is not an issue, there are some networks that exceed this number of neighbors. This extension only contributes to additional memory overhead of the imple- mentation if the Hello Packets are maintained (a rare but not unthink- able occurrence). 4.3 The Link-State Advertisement Header All link-state advertisements begin with a common header. This header contains enough information to uniquely identify the advertisement (LS type, Link-State ID, and Advertising Router). This header is used in database description packets, link-state advertisements and link-state acknowledgement packets. The effects of extending the link-state ID and the advertising router fields to 128 bits is that the link-state header for OSPFv6 is 44 octets (was 20 octets for OSPFv4). This clearly increases the memory requirements as the LSA headers are stored in the link-state database for every link-state advertisement. The effects on fragmentation are specific to the packet using the link-state advertisement header. 4.4 The Database Description Packet Database description packets are exchanged when an adjacency is being initialized. They describe the contents of the topological database. Multiple packets may be used to describe the database. Each database description packet consists of the database description header and after the initial master/slave determination is complete, a list of link-state advertisement headers. The database description packet has an explicit fragmentation mechanism so that an implementation should build database description packets of the appropriate size (i.e., to avoid IP fragmentation). Extending the link-state advertisement header and the OSPF packet header contributes very little to addi- tional memory overhead as database description packets are not usually stored after being sent. 4.5 The Link-State Request Packet Link-state request packets are used during the initial database exchange process to request the pieces of the neighbor's database that are more up to date than those held in the router's database. Multiple link-state request packets may need to be used in the database exchange. Sending of link-state request packets is the last step in bringing up an adjacency. Each link-state request packet includes a link-state request header and a list of requested advertisements. The requested advertisements are specified by an LS type, Link-State ID, and Advertising Router which uniquely identifies the advertisement, but not its instance as Link-State Request packets are understood to be requests for the most Coltun Expires June 1996 [Page 10] Internet Draft OSPFv6 December 1995 recent instance. In OSPFv6 the link-state ID and advertising router fields are extend to 128 bits. The link-state request packet has explicit fragmentation mechanism so that an implementation should build link-state request packets of the appropriate size (i.e., to avoid IP fragmentation). This extension contributes little to additional memory overhead as link-state request packets are not usually stored after being sent. 4.6 The Link-State Acknowledgment Packet Link-State Acknowledgment Packets are used to make the flooding of link-state advertisements reliable; flooded advertisements are expli- citly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link-State Acknowledgment packets. Multiple link-state advertisements can be acknowledged in a single Link-State Acknowledgment packet. The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of link-state adver- tisement headers. The database acknowledgement packet has an explicit fragmentation mechanism so that an implementation should build link- state acknowledgement packets of the appropriate size (i.e., to avoid IP fragmentation). Extending the link-state advertisement header and the OSPF packet header contributes very little to additional memory overhead as acknowledgement packets are not usually stored after being sent. 4.7 The Link-State Update Packet Link-State Update packets implement the flooding of link-state adver- tisements. Each Link-State Update packet carries a collection of link-state advertisements one hop further from its origin. Several link-state advertisements may be included in a single packet. For OSPFv6 the link-state ID field and advertising router field are 128 bits. Additionally, in the specific advertisements types (see below) fields that represent network/subnet numbers, interface addresses or router IDs are also 128 bits. Network mask fields (except for router LSAs) need not increase since a mask in OSPFv6 is an integer which represents the number of bits (length) of the network address mask. It is clear that the memory requirements for the link-state database for OSPFv6 is significantly greater than those for IPv4. Even though the link-state update packets have explicit fragmentation mechanism which allows an implementation to attempt to build link-state update packets of the appropriate size to avoid IP fragmentation there are issues that are specific to the link-state types that make it possible for a specific link-state advertisement to be larger than the required MTU. We now look at the issues unique to specific link-state adver- tisement types. Coltun Expires June 1996 [Page 11] Internet Draft OSPFv6 December 1995 4.7.1 The Router LSA Router link-state advertisements are originated by all routers. These LSAs consist of a list of interfaces to the area which may be a point-to-point connection to another router, a connections to a tran- sit network, a connection to a stub network, or virtual links. Each of these links includes the cost of the link. OSPF requires that all of the router's links to the area must be described in a single router LSA. The link ID and link data fields are now 128 bits making each link 36 octets (as opposed to 12 octets for OSPFv4). A router having greater than 40 links in its router LSA would exceed an Ethernet MTU. 4.7.2 The Network LSA Network link-state advertisements are originated for multi-access net- works by the Designated Router. This advertisement contains a list of the router IDs for each of the routers attached to the network. Net- work LSAs are flooded throughout a single area only. Since the OSPFv6 router IDs are 128 bits each link is 16 octets (as opposed to 4 octets for OSPFv4). A transit network having greater than 90 routers attached would exceed an Ethernet MTU. Although for most networks this is not an issue, there are some networks that exceed this number of neighbors. 4.7.3 Summary LSA Summary link-state advertisements are the type-3 and type-4 link-state advertisements. These advertisements are originated by area border routers and sent into an area. A separate summary LSA is made for each destination (known to the router) which belongs to the AS, yet is outside the area. Type 3 link-state advertisements are used when the destination is an IP network. In this case the advertisement's link-state ID field is an IPv6 network number and the Network Mask Length field is an integer which represents the number of bits in the network number's mask. When the destination is an AS boundary router, a type-4 advertisement is used, the link-state ID field is the AS boundary router's OSPF router ID and the Network Mask Length field is unused (i.e., set to 0). Since the OSPFv6 Link-State IDs and Router IDs are 128 bits summary link advertisements are 52 octets (as opposed to 28 octets for OSPFv4); there are no fragmentation issues for summary link advertise- ments. 4.7.4 The AS External LSA AS external link-state advertisements are the type-5 link-state Coltun Expires June 1996 [Page 12] Internet Draft OSPFv6 December 1995 advertisements. These advertisements are originated by AS boundary routers. A separate advertisement is made for each destination (known to the router) which is external to the AS. AS external link-state advertisements usually describe a particular external destination. For these advertisements the Link-State ID field specifies an IP network number. AS external link advertisements are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the link-state ID is always set to IPv6DefaultDestination (0::0) and the Network Mask Length is set to 0. The Link-State ID and Router ID and are 128 bits. OSPFv6 does not include the forwarding address or the external route tag but does have a 32-bit Opaque LSA Reference field (see Section 3.3.3 "External LSA Forwarding Address And Route Tag"). The OSPFv6 AS external LSA is 56 octets (as opposed to 28 octets for OSPFv4); there are no fragmentation issues for AS external link adver- tisements. Coltun Expires June 1996 [Page 13] Internet Draft OSPFv6 December 1995 5.0 Protocol Packet Processing This section discusses the general processing of OSPFv6 routing proto- col packets. It is essentially section 8 of [OSPF] but includes the specific checks for Instance ID. It is very important that the router link-state databases remain syn- chronized. For this reason, routing protocol packets should get pre- ferential treatment over ordinary data packets, both in sending and receiving. Routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacen- cies). This means that all routing protocol packets travel a single IP hop, except those sent over virtual links. All routing protocol packets begin with a standard header. The sec- tions below provide details on how to fill in and verify this standard header. Then, for each packet type, the section giving more details on that particular packet type's processing is listed. 5.1 Sending Protocol Packets When a router sends a routing protocol packet, it fills in the fields of the standard OSPF packet header as follows. For more details on the header format consult Section A.3.1 of this document: Version # Set to 2, the version number of the protocol as documented in this specification. Packet type The type of OSPF packet, such as a Link-State Update or Hello Packet. Packet Length The length of the entire OSPF packet in octets, including the standard OSPF packet header. Router ID The identity of the router itself (who is originating the packet). Area ID The OSPF area that the packet is being sent into. Instance ID The OSPFv6 instance that is originating the packet. See Section 3.4.2 of this document for more details. AuType and Authentication Each OSPF packet exchange is authenticated. Authentication Coltun Expires June 1996 [Page 14] Internet Draft OSPFv6 December 1995 types are assigned by the protocol and are documented in Appendix D of [OSPF]. A different authentication procedure can be used for each IP network/subnet. Autype indicates the type of authentication procedure in use. The 64-bit authen- tication field is then for use by the chosen authentication procedure. This procedure should be the last called when forming the packet to be sent. See Section D.4 of [OSPF] for details. The IPv6 destination address for the packet is selected as follows. On physical point-to-point networks, the IPv6 destination is always set to the address Allv6SPFRouters. On all other network types (including virtual links), the majority of OSPF packets are sent as unicasts, i.e., sent directly to the other end of the adjacency. In this case, the IPv6 destination is just the Neighbor'ss IPv6 address associated with the other end of the adjacency (see Section 10 of [OSPF]). The only packets not sent as unicasts are on broadcast net- works; on these networks Hello packets are sent to the multicast des- tination Allv6SPFRouters, the Designated Router and its Backup send both Link-State Update Packets and Link-State Acknowledgment Packets to the multicast address Allv6SPFRouters, while all other routers send both their Link-State Update and Link-State Acknowledgment Packets to the multicast address Allv6DRouters. Retransmissions of Link-State Update packets are ALWAYS sent as uni- casts. The IPv6 source address should be set to the IPv6 address of the send- ing interface. Interfaces to unnumbered point-to-point networks have no associated IPv6 address. On these interfaces, the IP source should be set to any of the other IPv6 addresses belonging to the router. For this reason, there must be at least one IPv6 address assigned to the router. Note that, for most purposes, virtual links act precisely the same as unnumbered point-to-point networks. However, each virtual link does have an IPv6 interface address (discovered during the routing table build process) which is used as the IP source when sending pack- ets over the virtual link. For more information on the format of specific OSPF packet types, con- sult the sections listed in Table 1. Type Packet name Detailed section (transmit) _________________________________________________________ 1 Hello Section 9.5 of [OSPF] 2 Database Description Section 10.8 of [OSPF] 3 Link-State Request Section 10.9 of [OSPF] 4 Link-State Update Section 13.3 of [OSPF] 5 Link-State Ack Section 13.5 of [OSPF] Coltun Expires June 1996 [Page 15] Internet Draft OSPFv6 December 1995 Table 1: Sections describing OSPF protocol packet transmission. 5.2 Receiving Protocol Packets Whenever a protocol packet is received by the router it is marked with the interface it was received on. For routers that have virtual links configured, it may not be immediately obvious which interface to asso- ciate the packet with. For example, consider the Router RT11 depicted in Figure 6 of [OSPF]. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link. In order for the packet to be accepted at the IP level, it must pass a number of tests, even before the packet is passed to appropriate OSPF Instance for processing: o The packet's IPv6 destination address must be the IPv6 address of the receiving interface, or one of the IPv6 multicast addresses Allv6SPFRouters or Allv6DRouters. o The IP protocol specified must be OSPF (89). o Locally originated packets should not be passed on to OSPF. That is, the source IPv6 address should be examined to make sure this is not a multicast packet that the router itself generated. Next, the OSPF packet header is verified. The fields specified in the header must match those configured for the receiving interface. If they do not, the packet should be discarded: o The version number field must specify protocol version 2. o The Instance ID found in the OSPF header must match the Instance ID of one of the OSPF instances bound to the receiving interface. Upon locating the OSPF instance all protocol process- ing of this packet will be associated with this OSPF instance. If no OSPF instance is located the packet is discarded. o The Area ID found in the OSPF header must be verified. If both of the following cases fail, the packet should be discarded. The Area ID specified in the header must either: (1) Match the Area ID of the receiving OSPF interface. In this case, the packet has been sent over a single hop. Therefore, the packet's IPv6 source address is required to be on the same net- work as the receiving interface. This can be verified by compar- ing the packet's IPv6 source address to the OSPF interface's IPv6 address, after masking both addresses with the interface's net- work mask. This comparison should not be performed on point-to- point networks. On point-to-point networks, the interface Coltun Expires June 1996 [Page 16] Internet Draft OSPFv6 December 1995 addresses of each end of the link are assigned independently, if they are assigned at all. (2) Indicate the backbone. In this case, the packet has been sent over a virtual link. The receiving router must be an area border router, and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. The receiving OSPF interface must also attach to the virtual link's configured Transit area. If all of these checks succeed, the packet is accepted and is from now on associated with the virtual link (and the backbone area). o Packets whose IPv6 destination is Allv6DRouters should only be accepted if the state of the receiving interface is DR or Backup (see Section 9.1). o The AuType specified in the packet must match the AuType speci- fied for the associated area. o The packet must be authenticated. The authentication procedure is indicated by the setting of AuType (see Appendix D of [OSPF]). The authentication procedure may use one or more Authentication keys, which can be configured on a per- interface basis. The authentication procedure may also verify the checksum field in the OSPFv6 packet header (which, when used, is set to the stan- dard IP 16-bit one's complement checksum of the OSPFv6 packet's contents after excluding the 64-bit authentication field). If the authentication procedure fails, the packet should be dis- carded. If the packet type is Hello, it should then be further processed by the Hello Protocol (see Section 10.5 of [OSPF]). All other packet types are sent/received only on adjacencies. This means that the packet must have been sent by one of the router's active neighbors. If the receiving interface connects to a broadcast network, Point-to- MultiPoint network or NBMA network the sender is identified by the IPv6 source address found in the packet's IPv6 header. If the receiv- ing interface connects to a point-to-point network or a virtual link, the sender is identified by the Router ID (source router) found in the packet's OSPFv6 header. The data structure associated with the receiving interface contains the list of active neighbors. Packets not matching any active neighbor are discarded. At this point all received protocol packets are associated with an active neighbor. For the further input processing of specific packet types, consult the sections listed in Table 2. Type Packet name Detailed section (receive) ________________________________________________________ 1 Hello Section 10.5 of [OSPF] 2 Database description Section 10.6 of [OSPF] 3 Link-state request Section 10.7 of [OSPF] Coltun Expires June 1996 [Page 17] Internet Draft OSPFv6 December 1995 4 Link-state update Section 13 of [OSPF] 5 Link-state ack Section 13.7 of [OSPF] Table 2: Sections describing OSPF protocol packet reception. Coltun Expires June 1996 [Page 18] Internet Draft OSPFv6 December 1995 6.0 Opaque LSAs Opaque LSAs are the Type 15 link-state advertisements. These adver- tisements are originated by any router and may be used directly by OSPFv6 as well as to provide for future extensibility. The Opaque LSA may also be used by other protocols such as BGP wishing to distribute information throughout the OSPFv6 domain. This information isn't used directly by OSPFv6. The contents of the Opaque LSA is some number of octets padded to 32- bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. Flooding Scope identifies the range of the topology to which this LSA may be distributed to. The following denotes the possible values of the Flooding Scope field. o A value of 0 denotes a link-local scope. Opaque LSAs with a Flooding Scope of 0 are not flooded beyond the local (sub)network. o A value of 1 denotes an area-local scope. Opaque LSAs with a flooding scope of 1 are not flooded beyond the area that they are originated into. o A value of 2 denotes that the LSA is flooded throughout (but not beyond) the routing domain. That is the information contained within these LSAs will not be distributed to any protocols beyond OSPFv6. o A value of 3 or greater denotes distribution throughout as well as beyond the routing domain. Origination of Opaque LSAs are unique to the application using it. OSPFv6 used the Opaque LSA as a replacement for OSPFv4's external LSA's forwarding address and route tag as explained in section 3.3.3 above. The link-state ID of the Opaque LSA is divided into a type field (the first 32 bits) a type-specific ID (the second 32-bit field) and a reserved field (the remaining 64 bits). The packet format of the AS External Reference Opaque LSA is given in section A.4.6.1 of this document. The responsibility of proper handling of the Opaque LSA's Flooding Scope field is both on the sender and receiver. The receiver must always store a valid received Opaque LSA in its link-state database. Flooding scope effects both the building of the Database summary list during the initial synchronization of the link-state database and the flooding procedure. The following describes the modifications to these procedures necessary for insuring proper use of the Opaque LSA's Scoping Rules. Coltun Expires June 1996 [Page 19] Internet Draft OSPFv6 December 1995 6.1 Modifications To The Neighbor State Machine The state machine as it exists in section 10.3 of [OSPF] remains unchanged except for the action associated with State: ExStart, Event: NegotiationDone which is where the Database summary list is built. To incorporate the Opaque LSA in OSPFv6 the action is changed to the fol- lowing. State(s): ExStart Event: NegotiationDone New state: Exchange Action: The router must list the contents of its entire area link-state database in the neighbor Database summary list. The area link-state database consists of the Router LSAs, Network LSAs and Summary LSAs contained in the area structure, along with Opaque and AS External LSAs contained in the global structure. AS External LSAs are omitted from a virtual neighbor's Database summary list. AS External LSAs are omitted from the Database summary list if the area has been configured as a stub (see Section 3.6 of [OSPF]). Opaque LSAs are omitted from the from the Database summary list if the following conditions are met: 1) the Flooding Scope is link-local and the interface address and mask in the Opaque LSA does not equal the interface address and mask found in the neighbor's interface; 2) the Flooding Scope is area-local and the area associated with Opaque LSA is not the area associated with the neighbor's interface, see Appendix A.4.6 of this document. Any advertisement whose age is equal to MaxAge is omitted from the Database summary list. It is instead added to the neighbor's link-state retransmission list. A summary of the Database summary list will be sent to the neighbor in Database Description packets. Each Database Description Packet has a DD sequence number, and is explicitly acknowledged. Only one Database Description Packet is allowed outstanding at any one time. For more detail on the sending and receiving of Database Description packets, see Sections 10.8 and 10.6 of [OSPF]. 6.2 Modifications To The Flooding Procedures Coltun Expires June 1996 [Page 20] Internet Draft OSPFv6 December 1995 The flooding of Opaque LSAs must follow the rules of Flooding Scope as denoted in this section. The flooding mechanisms must therefore suppress the flooding of Opaque LSAs as follows. o If the Flooding Scope is link-local and the interface address and mask in the Opaque advertisement does not equal the address and mask found in the neighbor's interface the Opaque LSA must not be flooded out or received by the interface. o If the Flooding Scope is area-local and the area associated with Opaque LSA is not the area associated with the neighbor's interface the Opaque LSA must not be flooded out the interface. The Flooding Scope rules affect Section 13 ("The Flooding Procedure") in [OSPF]. Coltun Expires June 1996 [Page 21] Internet Draft OSPFv6 December 1995 7.0 AS External Routes 7.1 Origination Of AS External Reference Opaque LSA As explained in Section 3.3.3 of this document the formats of the AS External LSA has changed. Instead of embedding the Forwarding Address and the Route Tag in the external LSA, the external LSA has an Opaque LSA Reference field. This field "references" an Opaque LSA containing a Forwarding Address and information that was previously stored in the Route Tag. OSPFv6 therefore must maintain a list of unique pairs and a 32-bit identifier for each of these pairs. (Since the goal of the Opaque LSA is to reduce the size of the link-state database, a single Opaque LSA should be originated containing a unique .) AS boundary routers originating AS External LSAs that require either a Forwarding Address or Route Tag information, must originate Opaque LSAs which are referenced in the Opaque LSA Reference field of the AS External LSA. (see Appendix A.4.6.2 for the format of the AS External Reference Opaque LSA). 7.2 Calculating AS External Routes For performing routing table calculations on AS External LSAs, there is an extra level of indirection needed so that a router 1) must have a valid path to the originator of the AS External route; 2) locate the referenced Opaque LSA in its link-state database and 3) validate the forwarding address contained in the Opaque LSA before it adds it con- siders the AS External route valid. To accommodate the changes to the AS External LSA packet format, the following replaces 16.4 of [OSPF]. AS external routes are calculated by examining AS external LSAs. Each of the AS external LSAs is considered in turn. Most AS external LSAs describe routes to specific IP destinations. An AS external LSAs can also describe a default route for the Autonomous System (Destination ID = 0::0, subnet mask length = 0). For each AS external link adver- tisement: (1) If the cost specified by the advertisement is LSInfinity, or if the advertisement's LS age is equal to MaxAge, then examine the next advertisement. (2) If the advertisement was originated by the calculating router itself, examine the next advertisement. (3) Call the destination described by the advertisement N. N's address is obtained by masking the advertisement's Link-State ID with the network/subnet mask which is referenced by the network Mask Length Field (i.e., the length of the network mask in bits) in the advertisement. Look up the routing table entry for the AS boundary router (ASBR) that originated the advertisement. If no Coltun Expires June 1996 [Page 22] Internet Draft OSPFv6 December 1995 entry exists for router ASBR (i.e., ASBR is unreachable), do nothing with this advertisement and consider the next in the list. Else, this advertisement describes an AS external path to desti- nation N. Examine the Opaque LSA Reference field in the AS External LSA. If the field is set to 0x00000000 packets should be set to the ASBR itself. Otherwise look up the Opaque LSA in the link-state database. The Opaque LSA was originated by the AS boundary router that originated the external advertisement. The Link-State ID of Opaque LSA is <1, Opaque ID Reference, 0, 0> (see Appendix A.4.6.2 for the format of the AS External Reference Opaque LSA). Examine the forwarding address specified in the Opaque LSA. This indicates the IP address to which packets for the destination should be forwarded. If the forwarding address is set to 0::0, packets should be sent to the ASBR itself. Otherwise, look up the forwarding address in the routing table. An intra-area or inter- area path must exist to the forwarding address. If no such path exists, do nothing with the advertisement and consider the next in the list. Call the routing table distance to the forwarding address X (when the forwarding address is set to 0::0, this is the distance to the ASBR itself), and the cost specified in the advertisement Y. X is in terms of the link-state metric, and Y is a type 1 or 2 external metric. (4) Next, look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with next hop equal to the list of next hops to the forwarding address, and advertising router equal to ASBR. If the external metric type is 1, then the path-type is set to type 1 external and the cost is equal to X+Y. If the external metric type is 2, the path-type is set to type 2 external, the link-state component of the route's cost is X, and the type 2 cost is Y. (5) Else, if the paths present in the table are not type 1 or type 2 external paths, do nothing (AS external paths have the lowest priority). (6) Otherwise, compare the cost of this new AS external path to the ones present in the table. Type 1 external paths are always shorter than type 2 external paths. Type 1 external paths are compared by looking at the sum of the distance to the forwarding address and the advertised type 1 metric (X+Y). Type 2 external paths are compared by looking at the advertised type 2 metrics, and then if necessary, the distance to the forwarding addresses. If the new path is shorter, it replaces the present paths in the routing table entry. If the new path is the same cost, it is added to the routing table entry's list of paths. Coltun Expires June 1996 [Page 23] Internet Draft OSPFv6 December 1995 8.0 References [OSPF] Moy, J., "OSPF Version 2", IETF Internet Draft, Cascade, November 1995. [IPV6] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", IETF Internet Draft, Xerox PARC, Ipsilon, June 1995 [IPV6ADDR] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", IETF Internet Draft Xerox PARC, Ipsilon, June 1995 [BGPOSPF] Varadhan, K., Hares, S., Rekhter, Y., "BGP4/IDRP for IP---OSPF Interaction", RFC1745, December 1994 [CIDR] 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. [IDRP] Kunzinger, C., Editor, "INTER-DOMAIN ROUTING PROTOCOL (IDRP)", IETF Internet Draft version of ISO10747, IBM Corp., June 1995 [PMTU] McCann, J., Deering, S., "Path MTU Discovery for IP version 6", IETF Internet Draft, Digital Equipment Corporation, Xerox PARC, November 6, 1995 [MOPSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., March 1994. [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, RainbowBridge Communications, Stanford University, March 1994. [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, Cascade, April 1995. Coltun Expires June 1996 [Page 24] Internet Draft OSPFv6 December 1995 Appendix A: OSPFv6 Data formats This appendix describes the format of OSPFv6 protocol packets and OSPFv6 link-state advertisements. The OSPFv6 protocol runs directly over the IP version 6 network layer. Before any data formats are described, the details of the OSPFv6 encapsulation are explained. Next the OSPFv6 Options field is described. This field describes vari- ous capabilities that may or may not be supported by pieces of the OSPFv6 routing domain. The OSPFv6 Options field is contained in OSPFv6 Hello packets, Database Description packets and in OSPFv6 link-state advertisements. OSPFv6 packet formats are detailed in Section A.3. A description of OSPFv6 link-state advertisements appears in Section A.4. A.1 Encapsulation Of OSPFv6 Packets OSPFv6 runs directly over the Internet Protocol's version 6 network layer. OSPFv6 packets are therefore encapsulated solely by IPv6 and local data-link headers. OSPFv6 does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the network MTU. The OSPFv6 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 packets sent over virtual links to 576 octets. Alternately, OSPFv6 routers may run "Path MTU Discovery for IP version 6" [PMTU] between virtual neighbors so as to discover the optimal size path MTU between the virtual neighbors. However, if necessary, the length of OSPF packets can be up to 65,535 octets (including the IPv6 header). The other important features of OSPFv6's IP encapsulation are: o Use of IP multicast. Some OSPFv6 messages are multicast, when sent over broadcast networks. Two distinct IPv6 multicast addresses are used. Packets sent to these multicast addresses should never be for- warded; they are meant to travel a single hop only. To ensure that these packets will not travel multiple hops, their IPv6 Hop Limit must be set to 1. Allv6SPFRouters For IPv6 this multicast address has been assigned the value FF02:0:0:0:0:0:0:5 (which has a link-local scope). All routers running OSPFv6 should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPFv6 protocol packets are sent to this address during the flooding procedure. Coltun Expires June 1996 [Page 25] Internet Draft OSPFv6 December 1995 Allv6DRouters This multicast address has been assigned the value FF02:0:0:0:0:0:0:6 (which has a link-local scope). Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPFv6 pro- tocol packets are sent to this address during the flooding pro- cedure. o OSPFv6 is IPv6 protocol number 89. This number has been registered with the Network Information Center. IP protocol number assignments are documented in [11]. o Routing protocol packets are sent with IPv6 Priority of 7 (internet control traffic). o Routing protocol packets are sent with IPv6 Priority of Internet Control Traffic (type 7). OSPFv6 protocol packets should be given precedence over regular IPv6 data traffic, in both sending and receiv- ing. Setting the IPv6 Priority field in the IPv6 header to Internet- work Control Traffic may help implement this objective. Coltun Expires June 1996 [Page 26] Internet Draft OSPFv6 December 1995 A.2 The Options Field The OSPFv6 Options field is present in OSPFv6 Hello packets, Database Description packets and all link-state advertisements. The Options field enables OSPFv6 routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPFv6 routers. Through this mechanism routers of differing capabili- ties can be mixed within an OSPFv6 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 link-state advertisements to a neighbor because of its reduced functionality. Lastly, listing capabilities in link-state advertisements allows routers to forward traffic around reduced functionality routers, by excluding them from parts of the routing table calculation. Six bits of the OSPFv6 Options field have been assigned, although only two (the T-bit and E-bit) are described completely by this memo. 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 link-state adver- tisements. Conversely, routers encountering unrecognized Option bits in received Hello Packets, Database Description packets or link-state advertisements should ignore the capability and process the packet/advertisement normally. +------------------------------------+ | * | * | DC | * | N/P | MC | E | T | +------------------------------------+ The Options Field R-bit This bit is reserved for future TOS/QOS capability definitions. 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 [OSPF]. MC-bit This bit describes whether IP multicast datagrams are forwarded according to the specifications in [MOSPF]. N/P-bit This bit describes the handling of Type-7 LSAs, as specified in [NSSA]. DC-bit This bit describes the router's handling of demand circuits, as Coltun Expires June 1996 [Page 27] Internet Draft OSPFv6 December 1995 specified in [DEMD]. Coltun Expires June 1996 [Page 28] Internet Draft OSPFv6 December 1995 A.3 OSPFv6 Packet Formats There are five distinct OSPFv6 packet types. All OSPFv6 packet types begin with a standard 24-octets 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 OSPFv6 packet types (other than the OSPFv6 Hello packets) deal with lists of link-state advertisements. For example, Link-State Update packets implement the flooding of advertisements throughout the OSPFv6 routing domain. Because of this, OSPFv6 protocol packets cannot be parsed unless the format of link-state advertisements is also understood. The format of the link-state advertisements packet is given in Section A.4. The receive processing of OSPFv6 packets is detailed in Section 5.2 of this document. The sending of OSPFv6 pack- ets is explained in Section 5.1 of this document. A.3.1 The OSPFv6 Packet Header Every OSPFv6 packet starts with a standard 48-octet header. This header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 5.0 of this document. 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 | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | Coltun Expires June 1996 [Page 29] Internet Draft OSPFv6 December 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version # The OSPFv6 version number. This specification documents version 2 of the 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 OSPFv6 protocol packet in octets. This length includes the standard OSPFv6 header. Router ID The Router ID of the packet's source. Area ID A 128-bit number identifying the area that this packet belongs to. All OSPFv6 packets are associated with a single area. Most travel a single hop only. Packets traversing a virtual link are labeled with the backbone Area ID of 0::0. Checksum The standard IP checksum of the entire contents of the packet, starting with the OSPFv6 packet header but excluding the 64-bit authentication field. 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, excepting the authentication field. If the packet's length is not an integral number of 16-bit words, the packet is padded with an octet of zero before checksumming. The checksum is considered to be part of the packet authentication procedure; for some authentication types the checksum calculation is omitted. Instance ID This is a 8-bit number that uniquely identifies the OSPFv6 Instance (or process) within the router that will be accepting Coltun Expires June 1996 [Page 30] Internet Draft OSPFv6 December 1995 this packet. The Instance ID was added to OSPFv6 to facilitate identifying a particular OSPFv6 Instance by network management (to identify the particular instance to be managed) and by the OSPFv6 send and receive functions (to identify packet's target OSPFv6 instance). See Section 3.4.2 and Section 5 of this docu- ment for further details. AuType Identifies the authentication procedure to be used for the packet. Authentication is discussed in Appendix D of [OSPF]. Consult Appendix D of [OSPF] for a list of the currently defined authentication types. Authentication A 64-bit field for use by the authentication scheme. See Appendix D of the [OSPF] for details. Coltun Expires June 1996 [Page 31] Internet Draft OSPFv6 December 1995 A.3.2 The Hello Packet Hello packets are OSPFv6 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 physical networks having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers. All routers connected to a common network must agree on certain param- eters (Network mask, HelloInterval and RouterDeadInterval). These parameters are included in Hello packets, so that differences can inhibit the forming of neighbor relationships. A detailed explanation of the receive processing for Hello packets is presented in Section 10.5 of [OSPF]. The sending of Hello packets is covered in Section 9.5 of [OSPF]. 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 | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | Options | Rtr Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RouterDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | Coltun Expires June 1996 [Page 32] Internet Draft OSPFv6 December 1995 + Designated Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Backup Designated Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Neighbor + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Network Mask Length The length in bits of the network mask associated with this interface. Unlike OSPFv4 the network mask length for OSPFv6 is an integer representing the number of bits in the mask. For exam- ple, if the interface address is 1080:0:0:0:8:800:200C:417A and the network mask is FFFF:FFFF:FFFF:FFFF:FFFF:0:0:0 the Network Mask Length field is 80. Options The optional capabilities supported by the router, as documented in Appendix A.2 of this document. HelloInterval The number of seconds between this router's Hello packets. Rtr Pri This router's Router Priority as used in the (Backup) Designated Router election. If set to 0, the router will be ineligible to become (Backup) Designated Router. RouterDeadInterval The number of seconds before declaring a silent router down. Designated Router The identity of the Designated Router for this network, in the view of the sending router. The Designated Router is identified here by its IP interface address on the network. Set to 0::0 if there is no Designated Router. Coltun Expires June 1996 [Page 33] Internet Draft OSPFv6 December 1995 Backup Designated Router The identity of the Backup Designated Router for this network, in the view of the sending router. The Backup Designated Router is identified here by its IP interface address on the network. Set to 0::0 if there is no Backup Designated Router. Neighbor 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 Expires June 1996 [Page 34] Internet Draft OSPFv6 December 1995 A.3.3 The Database Description Packet Database Description packets are OSPFv6 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 | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | Options |0|0|0|0|0|I|M|MS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DD sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | A | +- Link-State Advertisement -+ | Header | +- -+ | | +- -+ | | Coltun Expires June 1996 [Page 35] Internet Draft OSPFv6 December 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 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 [OSPF]. The reception of Database Description packets is documented in Section 10.6 of [OSPF]. 0 These fields are reserved. They must be 0. Options The optional capabilities supported by the router, as documented in Section A.2 of this document. 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. Oth- erwise, the router is the slave. 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 com- plete database description has been sent. The rest of the packet consists of a (possibly partial) list of the link-state database's pieces. Each link-state advertisement in the database is described by its link-state advertisement header. The link-state advertisement header is documented in Section A.4.1. It contains all the information required to uniquely identify both the advertisement and the advertisement's current instance. Coltun Expires June 1996 [Page 36] Internet Draft OSPFv6 December 1995 A.3.4 The Link-State Request Packet Link-State Request packets are OSPFv6 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 pre- cise 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 the [OSPF]. The reception of Link-State Request packets is documented in Section 10.7 of [OSPF]. 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 | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | Coltun Expires June 1996 [Page 37] Internet Draft OSPFv6 December 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Each advertisement requested is specified by its LS type, Link-State ID, and Advertising Router. This uniquely identifies the advertise- ment, but not its instance. Link-State Request packets are understood to be requests for the most recent instance (whatever that might be). Coltun Expires June 1996 [Page 38] Internet Draft OSPFv6 December 1995 A.3.5 The Link-State Update Packet Link-State Update packets are OSPFv6 packet type 4. These packets implement the flooding of link-state advertisements. Each Link-State Update packet carries a collection of link-state advertisements one hop further from their origin. Several link-state advertisements 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 pro- cedure reliable, flooded advertisements are acknowledged in Link-State Acknowledgment packets. If retransmission of certain advertisements is necessary, the retransmitted advertisements are always carried by unicast Link-State Update packets. For more information on the reli- able flooding of link-state advertisements, consult Section 13 of [OSPF]. 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 | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # advertisements | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- +-+ | Link-State Advertisements | +- +-+ | ... | Coltun Expires June 1996 [Page 39] Internet Draft OSPFv6 December 1995 # advertisements The number of link-state advertisements included in this update. The body of the Link-State Update packet consists of a list of link- state advertisements. Each advertisement begins with a common 44- octet header, described in Section A.4.1. Detailed formats of the dif- ferent types of link-state advertisements are described in Section A.4. Coltun Expires June 1996 [Page 40] Internet Draft OSPFv6 December 1995 A.3.6 The Link-State Acknowledgment Packet Link-State Acknowledgment Packets are OSPFv6 packet type 5. To make the flooding of link-state advertisements reliable, flooded advertise- ments are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link-State Acknowledgment pack- ets. Multiple link-state advertisements can be acknowledged in a sin- gle 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 Allv6SPFRouters, to the multicast address Allv6DRouters, or as a unicast. The sending of Link-State Acknowledgement packets is documented in Section 13.5 of [OSPF]. The reception of Link-State Acknowledgement packets is docu- mented in Section 13.7 of [OSPF]. The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of link-state advertisement 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 | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- -+ Coltun Expires June 1996 [Page 41] Internet Draft OSPFv6 December 1995 | | +- -+ | | +- -+ | A | +- Link-State Advertisement -+ | Header | +- -+ | | +- -+ | | +- -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Each acknowledged link-state advertisement is described by its link- state advertisement header. The link-state advertisement header is documented in Section A.4.1 of this document. It contains all the information required to uniquely identify both the advertisement and the advertisement's current instance. Coltun Expires June 1996 [Page 42] Internet Draft OSPFv6 December 1995 A.4 Link-State Advertisement (LSA) Formats This memo defines five distinct types of link-state advertisements. Each link-state advertisement begins with a standard 44-octet link- state advertisement header. This header is explained in Section A.4.1 of this document. Succeeding sections then diagram the separate link-state advertisement types. Each link-state advertisement describes a piece of the OSPFv6 routing domain. Every router originates a router LSA. In addition, whenever the router is elected Designated Router, it originates a network LSA. Other types of link-state advertisements may also be originated (see Section 12.4 of [OSPF]). All link-state advertisements are then flooded throughout the OSPFv6 routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of link-state advertisements. (See Section 13 of [OSPF] for more infor- mation concerning the flooding algorithm). This collection of adver- tisements 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 [OSPF]). For the details of the routing table build process, see Section 16 of [OSPF]. A.4.1 The Link-State Advertisement Header All link-state advertisements begin with a common 44-octet header. This header contains enough information to uniquely identify the advertisement (LS type, Link-State ID, and Advertising Router). Mul- tiple instances of the link-state advertisement may exist in the rout- ing 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 link-state advertisement 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 | Options | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | Coltun Expires June 1996 [Page 43] Internet Draft OSPFv6 December 1995 + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS age The time in seconds since the link-state advertisement was ori- ginated. Options The optional capabilities supported by the described portion of the routing domain. OSPFv6's optional capabilities are docu- mented in Section A.2 of this document. LS type The type of the link-state advertisement. Each link-state type has a separate advertisement format. The link-state types defined in this memo are as follows (see Section 12.1.3 of [OSPF] for further explanation): LS Type Description ___________________________________ 1 Router LSA 2 Network LSA 3 Summary LSA (IP network) 4 Summary LSA (ASBR) 5 AS External LSA 15 Opaque LSA Link-State ID This field identifies the portion of the internet environment that is being described by the advertisement. The contents of this field depend on the advertisement's LS type. For example, in network LSAs the Link-State ID is set to the IPv6 interface address of the network's Designated Router (from which the network's IP address can be derived). The Link-State ID is further discussed in Section 12.1.4 in [OSPF]. Advertising Router The Router ID of the router that originated the link-state adver- tisement. For example, in network LSAs this field is equal to the Coltun Expires June 1996 [Page 44] Internet Draft OSPFv6 December 1995 Router ID of the network's Designated Router. LS sequence number Detects old or duplicate link-state advertisements. Successive instances of a link-state advertisement are given successive LS sequence numbers. See Section 12.1.6 of [OSPF] for more details. LS checksum The Fletcher checksum of the complete contents of the link-state advertisement, including the link-state advertisement header but excluding the LS age field. See Section 12.1.7 of [OSPF] for more details. Length The length in octets of the link-state advertisement. This includes the 44-octet link-state advertisement header. Coltun Expires June 1996 [Page 45] Internet Draft OSPFv6 December 1995 A.4.2 Router LSA Router LSAs are the Type 1 link-state advertisements. Each router in an area originates a router LSA. The advertisement describes the state and cost of the router's links (i.e., interfaces) to the area. All of the router's links to the area must be described in a single router LSA. For details concerning the construction of router LSAs, see Section 12.4.1 of [OSPF]. 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 | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link Data + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Metric | Coltun Expires June 1996 [Page 46] Internet Draft OSPFv6 December 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | In router LSAs, the Link-State ID field is set to the router's OSPFv6 Router ID. Router LSAs are flooded throughout a single area only. bit V When set, the router is an endpoint of an active virtual link that is using the described area as a Transit area (V is for vir- tual link endpoint). bit E When set, the router is an AS boundary router (E is for exter- nal). bit B When set, the router is an area border router (B is for border). # links The number of router links described in this advertisement. This must be the total collection of router links (i.e., interfaces) to the area. The following fields are used to describe each router link (i.e., interface). Each router link is typed (see the below Type field). The Type field indicates the kind of link being described. It may be a link to a transit network, to another router or to a stub network. The values of all the other fields describing a router link depend on the link's Type. For example, each link has an associated 128-bit Link Data field. For links to stub networks this field specifies the length of the network's IP address mask. For other link types the Link Data field specifies the router interface's IP address. When the Link Data field is the IP address mask length, the first 32-bit field is treated as an integer which contains the length in bits of the mask. Type A quick description of the router link. One of the following. Note that host routes are classified as links to stub networks with network mask length of 128. Type Description __________________________________________________ 1 Point-to-point connection to another router 2 Connection to a transit network 3 Connection to a stub network 4 Virtual link Coltun Expires June 1996 [Page 47] Internet Draft OSPFv6 December 1995 Link ID Identifies the object that this router link connects to. Value depends on the link's Type. When connecting to an object that also originates a link-state advertisement (i.e., another router or a transit network) the Link ID is equal to the neighboring advertisement's Link-State ID. This provides the key for looking up the neighboring advertisement in the link-state database dur- ing the routing table calculation. See Section 12.2 of [OSPF] for more details. Type Link ID ______________________________________ 1 Neighboring router's Router ID 2 IP address of Designated Router 3 IP network/subnet number 4 Neighboring router's Router ID Link Data Value again depends on the link's Type field. For connections to stub networks, Link Data specifies the bit-length of the network's IPv6 address mask. For unnumbered point-to-point con- nections, it specifies (in the first 32-bit field) the interface's MIB-II [8] ifIndex value. For the other link types it specifies the router interface's IP address. This latter piece of information is needed during the routing table build process, when calculating the IP address of the next hop. See Section 16.1.1 of [OSPF] for more details. Reserved Currently unused. Metric The cost of using this outbound router link. Coltun Expires June 1996 [Page 48] Internet Draft OSPFv6 December 1995 A.4.3 Network LSA Network LSAs are the Type 2 link-state advertisements. A network LSA is originated for each broadcast and NBMA network in the area which supports two or more routers. The network LSA is originated by the network's Designated Router. The advertisement describes all routers attached to the network, including the Designated Router itself. The advertisement's Link-State ID field lists the IP interface address of the Designated Router. The distance from the network to all attached routers is zero. For details concerning the construction of network LSAs, see Section 12.4.2 of [OSPF]. 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 | Options | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Attached Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Coltun Expires June 1996 [Page 49] Internet Draft OSPFv6 December 1995 Network Mask Length The length in bits of the network mask associated with this interface. Unlike OSPFv4 the network mask length for OSPFv6 is an integer representing the number of bits in the mask. For exam- ple, if the interface address is 1080:0:0:0:8:800:200C:417A and the network mask is FFFF:FFFF:FFFF:FFFF:FFFF:0:0:0 the Network Mask Length field is 80. Attached Router The Router IDs of each of the routers attached to the network. 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 link-state advertisement header's length field. Coltun Expires June 1996 [Page 50] Internet Draft OSPFv6 December 1995 A.4.4 Summary LSA Summary LSA are the Type 3 and 4 link-state advertisements. These advertisements are originated by area border routers. Summary link advertisements describe inter-area destinations. For details concern- ing the construction of summary link advertisements, see Section 12.4.3 of [OSPF]. Type 3 link-state advertisements are used when the destination is an IPv6 network. In this case the advertisement's Link-State ID field is an IPv6 network number (if necessary, the Link-State ID can also have one or more of the network's "host" bits set; see Appendix E of [OSPF] for details). When the destination is an AS boundary router, a Type 4 advertisement is used, and the Link-State ID field is the AS boundary router's OSPFv6 Router ID. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 of [OSPF].) Other than the difference in the Link-State ID field, the format of Type 3 and 4 link-state advertisements is identical. 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 | Options | 3 or 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | For stub areas, Type 3 summary link advertisements can also be used to describe a (per-area) default route. Default summary routes are used Coltun Expires June 1996 [Page 51] Internet Draft OSPFv6 December 1995 in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the advertisement's Link- State ID is always set to DefaultDestination (0::0) and the Network Mask Length is set to 0. Network Mask Length For Type 3 link-state advertisements, this indicates the number of bits in the destination network's IPv6 address mask. For example, when advertising the location of FF01:0::0 with the net- work mask of FFFF:0::0, the value of 16 would be used in the mask field. This field is not meaningful and must be zero for Type 4 link-state advertisements. Metric The cost of this route. Expressed in the same units as the inter- face costs in the router LSA. Reserved This field is currently unused. Coltun Expires June 1996 [Page 52] Internet Draft OSPFv6 December 1995 A.4.5 AS External LSA AS external link advertisements are the Type 5 link-state advertise- ments. These advertisements are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS external link advertisements, see Section 12.4.3 of [OSPF] and Section 7.0 of this document. AS external link advertisements usually describe a particular external destination. For these advertisements the Link-State ID field speci- fies an IP network number (if necessary, the Link-State ID can also have one or more of the network's "host" bits set; see Appendix E for details). AS external link advertisements are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link-State ID is always set to DefaultDestination (0::0) and the Network Mask Length 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 | Options | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link-State ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Reserved | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque LSA Reference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network Mask Length Coltun Expires June 1996 [Page 53] Internet Draft OSPFv6 December 1995 The number if bits in the IPv6 address mask for the advertised destination. For example, when advertising the location of FF01:0::0 with the network mask of FFFF:0::0, the value of 16 would be used in the mask field. bit E The type of external metric. If bit E is set, the metric speci- fied is a Type 2 external metric. This means the metric is con- sidered larger than any link-state 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). Metric The cost of this route. Interpretation depends on the external type indication (bit E above). Opaque LSA Reference A 32-bit field attached to each external route. The semantics of the Opaque LSA Reference for OSPFv6 is different than the OSPFv4 Route Tag in that it is used to reference an Opaque LSA (see Sec- tion 7.0 of this document) which may include the Forwarding Address as well as information which may be used for policy by other protocols resident in the AS boundary router (i.e., used to communicate information between AS boundary routers). If the External Route Tag is not set (i.e., set to zero), data traffic will be forwarded to the advertisement's originator. Coltun Expires June 1996 [Page 54] Internet Draft OSPFv6 December 1995 A.4.6 Opaque LSA Opaque LSAs are the Type 15 link-state advertisements. These adver- tisements are originated by any router and may be used directly by OSPFv6; they are a useful tool for providing for future extensibility to OSPFv6. The Opaque LSA may also be used by other protocols such as BGP wishing to distribute information throughout the OSPFv6 domain. The BGP information isn't used directly by OSPFv6. The contents of the Opaque LSA is some number of octets padded to 32- bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. However, the Opaque LSA has a Flooding Scope associated with it so that the scope of flooding may be link-local, area-local, the OSPFv6 routing domain or beyond. Origination of Opaque LSAs are unique to the application using it. Section 6 of this document describes the flooding procedures for the Opaque LSA. 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 | Options | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flooding Scope | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... | Coltun Expires June 1996 [Page 55] Internet Draft OSPFv6 December 1995 Syntax Of The Opaque LSA's Link-State ID The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 32 bits), an Opaque ID (the second 32-bit field) and a reserved field (the remaining 64 bits). Flooding Scope Flooding Scope identifies the range of the topology to which this LSA may be distributed to. The following denotes the possible values of the Flooding Scope field. o A value of 0 denotes a link-local scope. Opaque LSAs with a Flooding Scope of 0 are not flooded beyond the local (sub)network. The local network is identified by the interface's network number and network mask length. See Section A.4.6.1 below for a description of the Link-Local Opaque LSA. o A value of 1 denotes an area-local scope. Opaque LSAs with a flooding scope of 1 are not flooded beyond the area that they are originated into. o A value of 2 denotes that the LSA is flooded throughout (but not beyond) the routing domain. That is, the information con- tained within these LSAs will not be distributed to any protocols beyond OSPFv6. o A value of 3 or greater denotes distribution throughout as well as beyond the routing domain. Network Mask Length The Network Mask Length field is an integer representing the length in bits of the prefix's mask. This field may be used when the first 128 bits of the Opaque Information is an address prefix (the interpretation of this field is dependent on the Opaque Type). When unused the Network Mask Length should be set to 0. Coltun Expires June 1996 [Page 56] Internet Draft OSPFv6 December 1995 A.4.6.1 Link-Local Opaque LSA Link-Local Opaque LSAs the Type 15 link-state advertisements. These advertisements are originated by any router and may be used directly by OSPFv6; they are a useful tool for providing for future extensibil- ity to OSPFv6. The contents of the Opaque LSA is some number of octets padded to 32- bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. However, the Opaque LSA has a Flooding Scope associated with it so that the scope of flooding may be link-local, area-local, the OSPFv6 routing domain or beyond. This section pro- vides the packet format for Link-Local Opaque LSAs which must include the IPv6 address and mask of the IP interface to insure that the intended Flooding Scope is realized. Origination of Opaque LSAs are unique to the application using it. Section 6 of this document describes the flooding procedures for the Opaque LSA. 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 | Options | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flooding Scope = 0 | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Interface Address + | | Coltun Expires June 1996 [Page 57] Internet Draft OSPFv6 December 1995 + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... | Syntax Of The Opaque LSA's Link-State ID The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 32 bits), an Opaque ID (the second 32-bit field) and a reserved field (the remaining 64 bits). Flooding Scope Flooding Scope identifies the range of the topology to which this LSA may be distributed to. A value of 0 denotes a link-local scope. Opaque LSAs with a Flooding Scope of 0 are not flooded beyond the local (sub)network. Network Mask Length The Network Mask Length field is an integer representing the length in bits of the IPv6 interface network mask. The length is used along with the IPv6 interface address to insure that the intended Flooding Scope is realized. IPv6 Interface Address The IPv6 interface address representing the (sub)network to which the link-local flooding this Opaque LSA is limited to. The IPv6 Interface Address is used along with the Network Mask field to insure that the intended Flooding Scope is realized. Coltun Expires June 1996 [Page 58] Internet Draft OSPFv6 December 1995 A.4.6.2 AS External Reference Opaque LSA Opaque LSAs are the Type 15 link-state advertisements. AS External Reference Opaque LSA are originated by an AS boundary routers and used directly by OSPFv6 in conjunction with AS External LSAs. AS External Reference Opaque LSA are Opaque Type 1 LSAs. These are used to distribute the forwarding address, tag and origination infor- mation that were previously included in the AS External LSA. These are referenced by the Opaque LSA Reference field in the OSPFv6 AS External LSA by including the Opaque ID in Opaque LSA Reference field. Section 6 of this document describes the flooding procedures for the Opaque LSA. 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 | Options | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Advertising Router + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flooding Scope = 2 | Network Mask Length = 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Forwarding Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional External Route Tag | + + Coltun Expires June 1996 [Page 59] Internet Draft OSPFv6 December 1995 | ... | Opaque Type The Opaque Type for AS External Reference Opaque LSAs is 1. Opaque ID The Opaque ID is a local reference to the contents of the Opaque LSA which consists of the Forwarding Address, Origin Flags, Domain ID Length and Domain ID. Flooding Scope The Flooding Scope field of the AS External Reference Opaque LSA is set to 2 which denotes that the LSA is flooded throughout the routing domain but not distributed beyond the routing domain. Network Mask Length This field may be used when the first 128 bits of the Opaque Information is an address prefix (the interpretation of this field is dependent on the Opaque Type). For AS External Reference Opaque LSAs this field is set to 128 denoting that the Forwarding Address which follows is a host route. Forwarding Address Data traffic for the destination advertised in the referencing AS External LSA is forwarded to this address. If the Forwarding Address is set to 0::0, data traffic will be forwarded instead to the advertisement's originator (i.e., the responsible AS boundary router). Note that setting the Opaque LSA Reference field to 0 will also result in data traffic being forwarded to the advertisement's originator. Optional External Route Tag A 32-bit aligned variable length optional field that is not used by the OSPF protocol itself but may be used to communicate infor- mation between AS boundary routers. This information may be locally defined information, prefix origin information or a list of domain identifiers. The precise nature of such information is outside the scope of this specification. The length of the External Route Tag (which may be 0 if the field is omitted) may be determined by the LSA's length field. Coltun Expires June 1996 [Page 60] Internet Draft OSPFv6 December 1995 Appendix B: Architectural Constants Several OSPF protocol parameters have fixed architectural values. These parameters have been referred to in the text by names such as LSRefreshTime. The same naming convention is used for the configur- able protocol parameters. They are defined in Appendix C of this docu- ment and [OSPF]. The name of the OSPFv6 specific architectural constant follows, together with its value and a short description of its function. IPv6DefaultDestination The Destination ID that indicates the default route. This route is used when no other matching routing table entry can be found. The default destination can only be advertised in AS External LSA and in stub areas' type 3 summary LSAs. Its value is the IP address 0::0. Its associated Network Mask Length is always 0. Allv6SPFRouters For IPv6 this multicast address has been assigned the value FF02:0:0:0:0:0:0:5. All routers running OSPFv6 should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPFv6 protocol packets are sent to this address during the flooding procedure. This address has a link-local scope. See [IPV6ADDR] for a further description of IP version 6 Addresses Architecture. Allv6DRouters This IPv6 multicast address has been assigned the value FF02:0:0:0:0:0:0:6. Both the Designated Router and Backup Desig- nated Router must be prepared to receive packets destined to this address. Certain OSPFv6 protocol packets are sent to this address during the flooding procedure. This address has a link- local scope. See [IPV6ADDR] for a further description of IP ver- sion 6 Addresses Architecture. Coltun Expires June 1996 [Page 61] Internet Draft OSPFv6 December 1995 Appendix 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.). Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parame- ters, and all routers attached to a network must agree on that network's IP network number and mask. 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 confi- gurable. This specification gives the Global Parameters for OSPFv6. Appendix C of [OSPF] should be referred to for the remaining parameters. 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 128-bit number that uniquely identifies the router in the Autonomous System. One algorithm for Router ID assignment is to choose the largest or smallest IP address assigned to the router. 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 link state advertisements from the routing domain (see Section 14.1 of [OSPF]), or they will persist for up to MaxAge minutes. Instance ID This is a 8-bit number that uniquely identifies the OSPFv6 Instance (or process) within the router. The Instance ID was added to OSPFv6 to facilitate identifying a particular OSPFv6 Instance by network management (to identify the particular instance to be managed) and by the OSPFv6 send and receive func- tions (to identify packet's target OSPFv6 instance). See Section 3.4.2 and Section 5 of this document for further details. Coltun Expires June 1996 [Page 62]