Network Working Group R. Coltun Internet-Draft Acoustra Productions Obsoletes: 2740 (if approved) D. Ferguson Intended status: Standards Track Juniper Networks Expires: May 19, 2008 J. Moy Sycamore Networks, Inc A. Lindem (Editor) Redback Networks November 16, 2007 OSPF for IPv6 draft-ietf-ospf-ospfv3-update-18.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 19, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Coltun, et al. Expires May 19, 2008 [Page 1] Internet-Draft OSPF for IPv6 November 2007 Abstract This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload. Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs) are also supported in OSPF for IPv6. Coltun, et al. Expires May 19, 2008 [Page 2] Internet-Draft OSPF for IPv6 November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Differences from OSPF for IPv4 . . . . . . . . . . . . . . . 7 2.1. Protocol processing per-link, not per-subnet . . . . . . 7 2.2. Removal of addressing semantics . . . . . . . . . . . . . 7 2.3. Addition of Flooding scope . . . . . . . . . . . . . . . 8 2.4. Explicit support for multiple instances per link . . . . 8 2.5. Use of link-local addresses . . . . . . . . . . . . . . . 8 2.6. Authentication changes . . . . . . . . . . . . . . . . . 9 2.7. Packet format changes . . . . . . . . . . . . . . . . . . 9 2.8. LSA format changes . . . . . . . . . . . . . . . . . . . 10 2.9. Handling unknown LSA types . . . . . . . . . . . . . . . 12 2.10. Stub/NSSA area support . . . . . . . . . . . . . . . . . 12 2.11. Identifying neighbors by Router ID . . . . . . . . . . . 13 3. Implementation details . . . . . . . . . . . . . . . . . . . 14 3.1. Protocol data structures . . . . . . . . . . . . . . . . 15 3.1.1. The Area Data structure . . . . . . . . . . . . . . . 15 3.1.2. The Interface Data structure . . . . . . . . . . . . 16 3.1.3. The Neighbor Data Structure . . . . . . . . . . . . . 17 3.2. Protocol Packet Processing . . . . . . . . . . . . . . . 18 3.2.1. Sending protocol packets . . . . . . . . . . . . . . 18 3.2.1.1. Sending Hello Packets . . . . . . . . . . . . . . 19 3.2.1.2. Sending Database Description Packets . . . . . . 20 3.2.2. Receiving Protocol Packets . . . . . . . . . . . . . 20 3.2.2.1. Receiving Hello Packets . . . . . . . . . . . . . 22 3.3. The Routing table Structure . . . . . . . . . . . . . . . 23 3.3.1. Routing table lookup . . . . . . . . . . . . . . . . 24 3.4. Link State Advertisements . . . . . . . . . . . . . . . . 24 3.4.1. The LSA Header . . . . . . . . . . . . . . . . . . . 24 3.4.2. The link-state database . . . . . . . . . . . . . . . 25 3.4.3. Originating LSAs . . . . . . . . . . . . . . . . . . 25 3.4.3.1. LSA Options . . . . . . . . . . . . . . . . . . . 29 3.4.3.2. Router-LSAs . . . . . . . . . . . . . . . . . . . 29 3.4.3.3. Network-LSAs . . . . . . . . . . . . . . . . . . 31 3.4.3.4. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . 32 3.4.3.5. Inter-Area-Router-LSAs . . . . . . . . . . . . . 33 3.4.3.6. AS-external-LSAs . . . . . . . . . . . . . . . . 34 3.4.3.7. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . 35 3.4.3.8. Link-LSAs . . . . . . . . . . . . . . . . . . . . 36 3.4.3.9. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . 38 3.4.4. Future LSA Validation . . . . . . . . . . . . . . . . 41 3.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 41 3.5.1. Receiving Link State Update packets . . . . . . . . . 42 3.5.2. Sending Link State Update packets . . . . . . . . . . 42 3.5.3. Installing LSAs in the database . . . . . . . . . . . 44 Coltun, et al. Expires May 19, 2008 [Page 3] Internet-Draft OSPF for IPv6 November 2007 3.6. Definition of self-originated LSAs . . . . . . . . . . . 45 3.7. Virtual links . . . . . . . . . . . . . . . . . . . . . . 45 3.8. Routing table calculation . . . . . . . . . . . . . . . . 46 3.8.1. Calculating the shortest path tree for an area . . . 46 3.8.2. The next hop calculation . . . . . . . . . . . . . . 48 3.8.3. Calculating the inter-area routes . . . . . . . . . . 49 3.8.4. Examining transit areas' summary-LSAs . . . . . . . . 49 3.8.5. Calculating AS external and NSSA routes . . . . . . . 49 3.9. Multiple interfaces to a single link . . . . . . . . . . 50 3.9.1. Standby Interface State . . . . . . . . . . . . . . . 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 5.1. MOSPF for OSPFv3 Deprecation IANA Considerations . . . . 55 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 58 7.2. Informative References . . . . . . . . . . . . . . . . . 59 Appendix A. OSPF data formats . . . . . . . . . . . . . . . . . 60 A.1. Encapsulation of OSPF packets . . . . . . . . . . . . . . 60 A.2. The Options field . . . . . . . . . . . . . . . . . . . . 61 A.3. OSPF Packet Formats . . . . . . . . . . . . . . . . . . . 63 A.3.1. The OSPF packet header . . . . . . . . . . . . . . . 63 A.3.2. The Hello Packet . . . . . . . . . . . . . . . . . . 65 A.3.3. The Database Description Packet . . . . . . . . . . . 66 A.3.4. The Link State Request Packet . . . . . . . . . . . . 68 A.3.5. The Link State Update Packet . . . . . . . . . . . . 69 A.3.6. The Link State Acknowledgment Packet . . . . . . . . 70 A.4. LSA formats . . . . . . . . . . . . . . . . . . . . . . . 71 A.4.1. IPv6 Prefix Representation . . . . . . . . . . . . . 72 A.4.1.1. Prefix Options . . . . . . . . . . . . . . . . . 72 A.4.2. The LSA header . . . . . . . . . . . . . . . . . . . 73 A.4.2.1. LSA Type . . . . . . . . . . . . . . . . . . . . 75 A.4.3. Router-LSAs . . . . . . . . . . . . . . . . . . . . . 76 A.4.4. Network-LSAs . . . . . . . . . . . . . . . . . . . . 79 A.4.5. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . 80 A.4.6. Inter-Area-Router-LSAs . . . . . . . . . . . . . . . 81 A.4.7. AS-external-LSAs . . . . . . . . . . . . . . . . . . 82 A.4.8. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . 85 A.4.9. Link-LSAs . . . . . . . . . . . . . . . . . . . . . . 85 A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . 87 Appendix B. Architectural Constants . . . . . . . . . . . . . . 90 Appendix C. Configurable Constants . . . . . . . . . . . . . . . 91 C.1. Global parameters . . . . . . . . . . . . . . . . . . . . 91 C.2. Area parameters . . . . . . . . . . . . . . . . . . . . . 91 C.3. Router interface parameters . . . . . . . . . . . . . . . 93 C.4. Virtual link parameters . . . . . . . . . . . . . . . . . 95 C.5. NBMA network parameters . . . . . . . . . . . . . . . . . 95 C.6. Point-to-Multipoint network parameters . . . . . . . . . 96 Coltun, et al. Expires May 19, 2008 [Page 4] Internet-Draft OSPF for IPv6 November 2007 C.7. Host route parameters . . . . . . . . . . . . . . . . . . 96 Appendix D. Stub Area Unknown LSA Flooding Restriction Deprecated . . . . . . . . . . . . . . . . . . . . . 98 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 99 E.1. Changes from RFC 2740 to 00 Version . . . . . . . . . . . 99 E.2. Changes from the 00 Version to the 01 Version . . . . . . 99 E.3. Changes from the 01 Version to the 02 Version . . . . . . 100 E.4. Changes from the 02 Version to the 03 Version . . . . . . 100 E.5. Changes from the 03 Version to the 04 Version . . . . . . 100 E.6. Changes from the 04 Version to the 05 Version . . . . . . 101 E.7. Changes from the 05 Version to the 06 Version . . . . . . 101 E.8. Changes from the 06 Version to the 07 Version . . . . . . 101 E.9. Changes from the 07 Version to the 08 Version . . . . . . 101 E.10. Changes from the 08 Version to the 09 Version . . . . . . 102 E.11. Changes from the 09 Version to the 10 Version . . . . . . 102 E.12. Changes from the 10 Version to the 11 Version . . . . . . 102 E.13. Changes from the 11 Version to the 12 Version . . . . . . 103 E.14. Changes from the 12 Version to the 13 Version . . . . . . 103 E.15. Changes from the 13 Version to the 14 Version . . . . . . 103 E.16. Changes from the 14 Version to the 15 Version . . . . . . 104 E.17. Changes from the 15 Version to the 16 Version . . . . . . 104 E.18. Changes from the 16 Version to the 17 Version . . . . . . 104 E.19. Changes from the 17 Version to the 18 Version . . . . . . 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106 Intellectual Property and Copyright Statements . . . . . . . . . 107 Coltun, et al. Expires May 19, 2008 [Page 5] Internet-Draft OSPF for IPv6 November 2007 1. Introduction This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. This document is organized as follows. Section 2 describes the differences between OSPF for IPv4 and OSPF for IPv6 in detail. Section 3 provides implementation details for the changes. Appendix A gives the OSPF for IPv6 packet and LSA formats. Appendix B lists the OSPF architectural constants. Appendix C describes configuration parameters. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-KEYWORDS]. 1.2. Terminology This document attempts to use terms from both the OSPF for IPv4 specification ([OSPFV2]) and the IPv6 protocol specifications ([IPV6]). This has produced a mixed result. Most of the terms used both by OSPF and IPv6 have roughly the same meaning (e.g., interfaces). However, there are a few conflicts. IPv6 uses "link" similarly to IPv4 OSPF's "subnet" or "network". In this case, we have chosen to use IPv6's "link" terminology. "Link" replaces OSPF's "subnet" and "network" in most places in this document, although OSPF's network-LSA remains unchanged (and possibly unfortunately, a new link-LSA has also been created). The names of some of the OSPF LSAs have also changed. See Section 2.8 for details. In the context of this document, an OSPF instance is a separate protocol instance complete with its own protocol data structures (e.g., areas, interfaces, neighbors), link-state database, protocol state machines, and protocol processing (e.g., SPF calculation). Coltun, et al. Expires May 19, 2008 [Page 6] Internet-Draft OSPF for IPv6 November 2007 2. Differences from OSPF for IPv4 Most of the algorithms from OSPF for IPv4 [OSPFV2] have been preserved in OSPF for IPv6. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. The following subsections describe the differences between this document and [OSPFV2]. 2.1. Protocol processing per-link, not per-subnet IPv6 uses the term "link" to indicate "a communication facility or medium over which nodes can communicate at the link layer" ([IPV6]). "Interfaces" connect to links. Multiple IPv6 subnets can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IPv6 subnet (IPv6 prefix). For this reason, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet. The terms "network" and "subnet" used in the IPv4 OSPF specification ([OSPFV2]) should generally be replaced by link. Likewise, an OSPF interface now connects to a link instead of an IP subnet. This change affects the receiving of OSPF protocol packets, the contents of Hello packets, and the contents of network-LSAs. 2.2. Removal of addressing semantics In OSPF for IPv6, addressing semantics have been removed from the OSPF protocol packets and the main LSA types, leaving a network- protocol-independent core. In particular: o IPv6 Addresses are not present in OSPF packets, except in LSA payloads carried by the Link State Update packets. See Section 2.7 for details. o Router-LSAs and network-LSAs no longer contain network addresses, but simply express topology information. See Section 2.8 for details. o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the IPv4 size of 32-bits. They can no longer be assigned as (IPv6) addresses. o Neighboring routers are now always identified by Router ID. Previously, they had been identified by IPv4 address on broadcast, Coltun, et al. Expires May 19, 2008 [Page 7] Internet-Draft OSPF for IPv6 November 2007 NBMA, and point-to-multipoint links. 2.3. Addition of Flooding scope Flooding scope for LSAs has been generalized and is now explicitly coded in the LSA's LS type field. There are now three separate flooding scopes for LSAs: o Link-local scope. LSA is only flooded on the local link and no further. Used for the new link-LSA. See Section 3.4.3.8 for details. o Area scope. LSA is only flooded throughout a single OSPF area. Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter- area-router-LSAs, and intra-area-prefix-LSAs. o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in Router-LSAs for regular areas. 2.4. Explicit support for multiple instances per link OSPF now supports the ability to run multiple OSPF protocol instances on a single link. For example, this may be required on a NAP segment shared between several providers. Providers may be supporting separate OSPF routing domains that wish to remain separate even though they have one or more physical network segments (i.e., links) in common. In OSPF for IPv4 this was supported in a haphazard fashion using the authentication fields in the OSPF for IPv4 header. Another use for running multiple OSPF instances is if you want, for one reason or another, to have a single link belong to two or more OSPF areas. Support for multiple protocol instances on a link is accomplished via an "Instance ID" contained in the OSPF packet header and OSPF interface data structures. Instance ID solely affects the reception of OSPF packets and applies to normal OSPF interfaces and virtual links. 2.5. Use of link-local addresses IPv6 link-local addresses are for use on a single link, for purposes of neighbor discovery, auto-configuration, etc. IPv6 routers do not forward IPv6 datagrams having link-local source addresses [IP6ADDR]. Link-local unicast addresses are assigned from the IPv6 address range Coltun, et al. Expires May 19, 2008 [Page 8] Internet-Draft OSPF for IPv6 November 2007 FE80/10. OSPF for IPv6 assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical links [IP6ADDR]. On all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as the source address. A router learns the link-local addresses of all other routers attached to its links and uses these addresses as next hop information during packet forwarding. On virtual links, a global scope IPv6 address MUST be used as the source address for OSPF protocol packets. Link-local addresses appear in OSPF link-LSAs (see Section 3.4.3.8). However, link-local addresses are not allowed in other OSPF LSA types. In particular, link-local addresses MUST NOT be advertised in inter-area-prefix-LSAs (Section 3.4.3.4), AS-external-LSAs (Section 3.4.3.6), NSSA-LSAs (Section 3.4.3.7), or intra-area-prefix- LSAs (Section 3.4.3.9). 2.6. Authentication changes In OSPF for IPv6, authentication has been removed from the OSPF protocol. The "AuType" and "Authentication" fields have been removed from the OSPF packet header, and all authentication related fields have been removed from the OSPF area and interface data structures. When running over IPv6, OSPF relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/confidentiality of routing exchanges. Protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo- header (see Appendix A.3.1). 2.7. Packet format changes OSPF for IPv6 runs directly over IPv6. Aside from this, all addressing semantics have been removed from the OSPF packet headers, making it essentially "network-protocol-independent". All addressing information is now contained in the various LSA types only. In detail, changes in OSPF packet format consist of the following: Coltun, et al. Expires May 19, 2008 [Page 9] Internet-Draft OSPF for IPv6 November 2007 o The OSPF version number has been incremented from 2 to 3. o The Options field in Hello packets and Database Description packets has been expanded to 24-bits. o The Authentication and AuType fields have been removed from the OSPF packet header (see Section 2.6) o The Hello packet now contains no address information at all Rather, it now includes an Interface ID which the originating router has assigned to uniquely identify (among its own interfaces) its interface to the link. This Interface ID will be used as the network-LSA's Link State ID if the router becomes Designated-Router on the link. o Two option bits, the "R-bit" and the "V6-bit", have been added to the Options field for processing router-LSAs during the SPF calculation (see Appendix A.2). If the "R-bit" is clear an OSPF speaker can participate in OSPF topology distribution without being used to forward transit traffic; this can be used in multi- homed hosts that want to participate in the routing protocol. The V6-bit specializes the R-bit; if the V6-bit is clear an OSPF speaker can participate in OSPF topology distribution without being used to forward IPv6 datagrams. If the R-bit is set and the V6-bit is clear, IPv6 datagrams are not forwarded but datagrams belonging to another protocol family may be forwarded. o The OSPF packet header now includes an "Instance ID" which allows multiple OSPF protocol instances to be run on a single link (see Section 2.4). 2.8. LSA format changes All addressing semantics have been removed from the LSA header, router-LSAs, and network-LSAs. These two LSAs now describe the routing domain's topology in a network protocol independent manner. New LSAs have been added to distribute IPv6 address information and data required for next hop resolution. The names of some of IPv4's LSAs have been changed to be more consistent with each other. In detail, changes in LSA format consist of the following: o The Options field has been removed from the LSA header, expanded to 24 bits, and moved into the body of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs. See Appendix A.2 for details. Coltun, et al. Expires May 19, 2008 [Page 10] Internet-Draft OSPF for IPv6 November 2007 o The LSA Type field has been expanded (into the former Options space) to 16 bits, with the upper three bits encoding flooding scope and the handling of unknown LSA types (see Section 2.9). o Addresses in LSAs are now expressed as [prefix, prefix length] instead of [address, mask] (see Appendix A.4.1). The default route is expressed as a prefix with length 0. o Router-LSAs and network-LSAs now have no address information and are network protocol independent. o Router interface information MAY be spread across multiple router- LSAs. Receivers MUST concatenate all the router-LSAs originated by a given router when running the SPF calculation. o A new LSA called the link-LSA has been introduced. Link-LSAs have local-link flooding scope; they are never flooded beyond the link with which they are associated. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link, 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link, and 3) they allow the router to advertise a collection of Options bits to associate with the network-LSA that will be originated for the link. See Section 3.4.3.8 for details. o In IPv4, the router-LSA carries a router's IPv4 interface addresses, the IPv4 equivalent of link-local addresses. These are only used when calculating next hops during the OSPF routing calculation (see Section 16.1.1 of [OSPFV2]), so they do not need to be flooded past the local link. Hence, using link-LSAs to distribute these addresses is more efficient. Note that link- local addresses cannot be learned through the reception of Hellos in all cases. On NBMA links, next hop routers do not necessarily exchange hellos. Rather, these routers learn of each other's existence by way of the Designated Router (DR). o The Options field in the Network LSA is set to the logical OR of the Options that each router on the link advertises in its link- LSA. o Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs". Type-4 summary LSAs have been renamed "inter-area-router-LSAs". o The Link State ID in inter-area-prefix-LSAs, inter-area-router- LSAs, NSSA-LSAs, and AS-external-LSAs, has lost its addressing semantics and now serves solely to identify individual pieces of the Link State Database. All addresses or Router IDs that were formerly expressed by the Link State ID are now carried in the LSA Coltun, et al. Expires May 19, 2008 [Page 11] Internet-Draft OSPF for IPv6 November 2007 bodies o Network-LSAs and link-LSAs are the only LSAs whose Link State ID carries additional meaning. For these LSAs, the Link State ID is always the Interface ID of the originating router on the link being described. For this reason, network-LSAs and link-LSAs are now the only LSAs whose size cannot be limited: a network-LSA MUST list all routers connected to the link and a link-LSA MUST list all of a router's addresses on the link. o A new LSA called the intra-area-prefix-LSA has been introduced. This LSA carries all IPv6 prefix information that in IPv4 is included in router-LSAs and network-LSAs. See Section 3.4.3.9 for details. o Inclusion of a forwarding address or external route tag in AS- external-LSAs is now optional. In addition, AS-external-LSAs can now reference another LSA, for inclusion of additional route attributes that are outside the scope of the OSPF protocol. For example, this reference could be used to attach BGP path attributes to external routes. 2.9. Handling unknown LSA types Handling of unknown LSA types has been made more flexible so that, based on LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood. This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see the U-bit in Appendix A.4.2.1). The IPv4 OSPF behavior of simply discarding unknown types is unsupported due to the desire to mix router capabilities on a single link. Discarding unknown types causes problems when the Designated Router supports fewer options than the other routers on the link. 2.10. Stub/NSSA area support In OSPF for IPv4, stub and NSSA areas were designed to minimize link- state database and routing table sizes for the areas' internal routers. This allows routers with minimal resources to participate in even very large OSPF routing domains. In OSPF for IPv6, the concept of stub and NSSA areas is retained. In IPv6, of the mandatory LSA types, stub areas carry only router-LSAs, network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area- prefix-LSAs. NSSA areas are restricted to these types and, of course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types Coltun, et al. Expires May 19, 2008 [Page 12] Internet-Draft OSPF for IPv6 November 2007 carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs. 2.11. Identifying neighbors by Router ID In OSPF for IPv6, neighboring routers on a given link are always identified by their OSPF Router ID. This contrasts with the IPv4 behavior where neighbors on point-to-point networks and virtual links are identified by their Router IDs while neighbors on broadcast, NBMA, and Point-to-Multipoint links are identified by their IPv4 interface addresses. This change affects the reception of OSPF packets (see Section 8.2 of [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]) and the reception of Hello packets (Section 10.5 of [OSPFV2]). The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used. Coltun, et al. Expires May 19, 2008 [Page 13] Internet-Draft OSPF for IPv6 November 2007 3. Implementation details When going from IPv4 to IPv6, the basic OSPF mechanisms remain unchanged from those documented in [OSPFV2]. These mechanisms are briefly outlined in Section 4 of [OSPFV2]. Both IPv6 and IPv4 have a link-state database composed of LSAs and synchronized between adjacent routers. Initial synchronization is performed through the Database Exchange process, which includes the exchange of Database Description, Link State Request, and Link State Update packets. Thereafter, database synchronization is maintained via flooding, utilizing Link State Update and Link State Acknowledgment packets. Both IPv6 and IPv4 use OSPF Hello packets to discover and maintain neighbor relationships, as well as to elect Designated Routers and Backup Designated Routers on broadcast and NBMA links. The decision as to which neighbor relationships become adjacencies, along with the basic ideas behind inter-area routing, importing external information in AS-external-LSAs, and the various routing calculations are also the same. In particular, the following IPv4 OSPF functionality described in [OSPFV2] remains completely unchanged for IPv6: o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 of [OSPFV2], namely: Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets. While in some cases (e.g., Hello packets) their format has changed somewhat, the functions of the various packet types remain the same. o The system requirements for an OSPF implementation remain unchanged, although OSPF for IPv6 requires an IPv6 protocol stack (from the network layer on down) since it runs directly over the IPv6 network layer. o The discovery and maintenance of neighbor relationships, and the selection and establishment of adjacencies remain the same. This includes election of the Designated Router and Backup Designated Router on broadcast and NBMA links. These mechanisms are described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2]. o The link types (or equivalently, interface types) supported by OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, Point-to-Multipoint, and virtual links. o The interface state machine, including the list of OSPF interface states and events, and the Designated Router and Backup Designated Router election algorithm, remain unchanged. These are described Coltun, et al. Expires May 19, 2008 [Page 14] Internet-Draft OSPF for IPv6 November 2007 in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2]. o The neighbor state machine, including the list of OSPF neighbor states and events, remains unchanged. The neighbor state machine is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2]. o Aging of the link-state database, as well as flushing LSAs from the routing domain through the premature aging process, remains unchanged from the description in Sections 14 and 14.1 of [OSPFV2]. However, some OSPF protocol mechanisms have changed as previously described in Section 2 herein. These changes are explained in detail in the following subsections, making references to the appropriate sections of [OSPFV2]. The following subsections provide a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation. 3.1. Protocol data structures The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database, and the routing table. The top-level data structures for IPv6 remain those listed in Section 5 of [OSPFV2], with the following modifications: o All LSAs with known LS type and AS flooding scope appear in the top-level data structure, instead of belonging to a specific area or link. AS-external-LSAs are the only LSAs defined by this specification that have AS flooding scope. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized), and AS flooding scope also appear in the top-level data structure. 3.1.1. The Area Data structure The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type which have area flooding scope are contained in the IPv6 area data structure. This always includes the following LSA types: router- LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized) and area scope also appear in the area data structure. NSSA-LSAs are also included in an NSSA area's data structure. Coltun, et al. Expires May 19, 2008 [Page 15] Internet-Draft OSPF for IPv6 November 2007 3.1.2. The Interface Data structure In OSPF for IPv6, an interface connects a router to a link. The IPv6 interface structure modifies the IPv4 interface structure (as defined in Section 9 of [OSPFV2]) as follows: Interface ID Every interface is assigned an Interface ID, which uniquely identifies the interface with the router. For example, some implementations MAY be able to use the MIB-II IfIndex ([INTFMIB]) as Interface ID. The Interface ID appears in Hello packets sent out the interface, the link-local-LSA originated by router for the attached link, and the router-LSA originated by the router-LSA for the associated area. It will also serve as the Link State ID for the network-LSA that the router will originate for the link if the router is elected Designated Router. The interface ID for a virtual link is independent of the interface ID of the outgoing interface it traverses in the transit area. Instance ID Every interface is assigned an Instance ID. This should default to 0. It is only necessary to assign differently on those links that will contain multiple separate communities of OSPF Routers. For example, suppose that there are two communities of routers on a given ethernet segment that you wish to keep separate. The first community is assigned an Instance ID of 0 and all the routers in the first community will be assigned 0 as the Instance ID for interfaces connected to the ethernet segment. An Instance ID of 1 is assigned to the other routers' interfaces connected to the ethernet segment. The OSPF transmit and receive processing (see Section 3.2) will then keep the two communities separate. List of LSAs with link-local scope All LSAs with link-local scope and which were originated/flooded on the link belong to the interface structure that connects to the link. This includes the collection of the link's link-LSAs. IP interface address For IPv6, the IPv6 address appearing in the source of OSPF packets sent out the interface is almost always a link-local address. The one exception is for virtual links which MUST use one of the router's own global IPv6 addresses as IP interface address. Coltun, et al. Expires May 19, 2008 [Page 16] Internet-Draft OSPF for IPv6 November 2007 List of link prefixes A list of IPv6 prefixes can be configured for the attached link. These will be advertised by the router in link-LSAs, so that they can be advertised by the link's Designated Router in intra-area- prefix-LSAs. In OSPF for IPv6, each router interface has a single metric representing the cost of sending packets out the interface. In addition, OSPF for IPv6 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/ confidentiality of routing exchanges. For this reason, AuType and Authentication key are not associated with IPv6 OSPF interfaces. Interface states, events, and the interface state machine remain unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of [OSPFV2] respectively. The Designated Router and Backup Designated Router election algorithm also remains unchanged from the IPv4 election in Section 9.4 of [OSPFV2]. 3.1.3. The Neighbor Data Structure The neighbor structure performs the same function in both IPv6 and IPv4. Namely, it collects all information required to form an adjacency between two routers when such an adjacency becomes necessary. Each neighbor structure is bound to a single OSPF interface. The differences between the IPv6 neighbor structure and the neighbor structure defined for IPv4 in Section 10 of [OSPFV2] are: Neighbor's Interface ID The Interface ID that the neighbor advertises in its Hello packets must be recorded in the neighbor structure. The router will include the neighbor's Interface ID in the router's router-LSA when either a) advertising a point-to-point or point-to-multipoint link to the neighbor or b) advertising a link to a network where the neighbor has become Designated Router. Neighbor IP address The neighbor's IPv6 address contained as the source address in OSPF for IPv6 packets. This will be an IPv6 link-local address for all link types except virtual links. Neighbor's Designated Router The neighbor's choice of Designated Router is now encoded as a Router ID instead of as an IP address. Coltun, et al. Expires May 19, 2008 [Page 17] Internet-Draft OSPF for IPv6 November 2007 Neighbor's Backup Designated Router The neighbor's choice of Backup Designated Router is now encoded as a Router ID instead of as an IP address. Neighbor states, events, and the neighbor state machine remain unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of [OSPFV2] respectively. The decision as to which adjacencies to form also remains unchanged from the IPv4 logic documented in Section 10.4 of [OSPFV2]. 3.2. Protocol Packet Processing OSPF for IPv6 runs directly over IPv6's network layer. As such, it is encapsulated in one or more IPv6 headers with the Next Header field of the immediately encapsulating IPv6 header set to the value 89. As for OSPF for IPv4, OSPF for IPv6 OSPF routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies). OSPF packet types and functions are the same in both IPv4 and IPv6, encoded by the Type field of the standard OSPF packet header. 3.2.1. Sending protocol packets When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Appendix A.3.1) as follows: Version # Set to 3, the version number of the protocol as documented in this specification. Type The type of OSPF packet, such as Link State Update or Hello packet. Packet length The length of the entire OSPF packet in bytes, including the standard OSPF packet header. Router ID The identity of the router itself (who is originating the packet). Coltun, et al. Expires May 19, 2008 [Page 18] Internet-Draft OSPF for IPv6 November 2007 Area ID The OSPF area for the interface that the packet is being sent on. Instance ID The OSPF Instance ID associated with the interface that the packet is being sent out of. Checksum The standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1). Selection of OSPF routing protocol packets' IPv6 source and destination addresses is performed identically to the IPv4 logic in Section 8.1 of [OSPFV2]. The IPv6 destination address is chosen from among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP address associated with the other end of the adjacency (which in IPv6, for all links except virtual links, is an IPv6 link-local address). The sending of Link State Request packets and Link State Acknowledgment packets remains unchanged from the IPv4 procedures documented in Sections 10.9 and 13.5 of [OSPFV2] respectively. Sending Hello packets is documented in Section 3.2.1.1, and the sending of Database Description packets in Section 3.2.1.2. The sending of Link State Update packets is documented in Section 3.5.2. 3.2.1.1. Sending Hello Packets IPv6 changes the way OSPF Hello packets are sent in the following ways (compare to Section 9.5 of [OSPFV2]): o Before the Hello packet is sent out an interface, the interface's Interface ID MUST be copied into the Hello packet. o The Hello packet no longer contains an IP network mask since OSPF for IPv6 runs per-link instead of per-subnet. o The choice of Designated Router and Backup Designated Router are now indicated within Hellos by their Router IDs instead of by their IP interface addresses. Advertising the Designated Router (or Backup Designated Router) as 0.0.0.0 indicates that the Designated Router (or Backup Designated Router) has not yet been chosen. o The Options field within Hello packets has moved around, getting larger in the process. More options bits are now possible. Those Coltun, et al. Expires May 19, 2008 [Page 19] Internet-Draft OSPF for IPv6 November 2007 that MUST be set correctly in Hello packets are: The E-bit is set if and only if the interface attaches to a regular area, i.e., not a stub or NSSA area. Similarly, the N-bit is set if and only if the interface attaches to an NSSA area (see [NSSA]). Finally, the DC-bit is set if and only if the router wishes to suppress the sending of future Hellos over the interface (see [DEMAND]). Unrecognized bits in the Hello packet's Options field should be cleared. Sending Hello packets on NBMA networks proceeds for IPv6 in exactly the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2]. 3.2.1.2. Sending Database Description Packets The sending of Database Description packets differs from Section 10.8 of [OSPFV2] in the following ways: o The Options field within Database Description packets has moved around, getting larger in the process. More options bits are now possible. Those that MUST be set correctly in Database Description packets are: The DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [DEMAND]). Unrecognized bits in the Database Description packet's Options field should be cleared. 3.2.2. Receiving Protocol Packets Whenever a router receives an OSPF protocol packet 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 associate the packet with. For example, consider the Router RT11 depicted in Figure 6 of [OSPFV2]. 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 passed to OSPF for processing, the following tests must be performed on the encapsulating IPv6 headers: o The packet's IP destination address MUST be one of the IPv6 unicast addresses associated with the receiving interface (this includes link-local addresses), one of the IPv6 multicast addresses AllSPFRouters or AllDRouters, or an IPv6 global address (for virtual links). Coltun, et al. Expires May 19, 2008 [Page 20] Internet-Draft OSPF for IPv6 November 2007 o The Next Header field of the immediately encapsulating IPv6 header MUST specify the OSPF protocol (89). o Any encapsulating IP Authentication Headers (see [IPAUTH]) and the IP Encapsulating Security Payloads (see [IPESP]) MUST be processed and/or verified to ensure integrity and authentication/ confidentiality of OSPF routing exchanges. This is described in [OSPFV3-AUTH]. After processing the encapsulating IPv6 headers, the OSPF packet header is processed. The fields specified in the header must match those configured for the receiving OSPFv3 interface. If they do not, the packet SHOULD be discarded: o The version number field MUST specify protocol version 3. o The standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo-header, must be verified (see Appendix A.3.1). o The Area ID and Instance ID found in the OSPF header must be verified. If both of the following cases fail, the packet should be discarded. The Area ID and Instance ID specified in the header must either: 1. Match one of the Area ID(s) and Interface Instance ID(s) for the receiving link. Unlike IPv4, the IPv6 source address is not restricted to lie within the same IPv6 subnet as the receiving link. IPv6 OSPF runs per-link instead of per-IP- subnet. 2. Match the backbone area and other criteria for a configured virtual link. The receiving router must be an ABR (Area Border Router) and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. Additionally, the receiving link must have an OSPFv3 interface which attaches to the virtual link's configured transit area and the Instance ID must match the virtual link's Instance ID. If all of these checks succeed, the packet is accepted and is associated with the virtual link (and the backbone area). o Locally originated packets SHOULD NOT be processed by OSPF except for support of multiple interfaces attached to the same link as described in Section 3.9. Locally originated packets have a source address equal to one of the router's local addresses. Coltun, et al. Expires May 19, 2008 [Page 21] Internet-Draft OSPF for IPv6 November 2007 o Packets whose IPv6 destination is AllDRouters should only be accepted if the state of the receiving OSPFv3 interface is DR or Backup (see Section 9.1 [OSPFV2]). After header processing, the packet is further processed according to its OSPF packet type. OSPF packet types and functions are the same for both IPv4 and IPv6. If the packet type is Hello, it should then be further processed by the Hello packet processing as described in Section 3.2.2.1. 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. The neighbor is identified by the Router ID appearing in the received packet's OSPF header. Packets not matching any active neighbor are discarded. The receive processing of Database Description packets, Link State Request packets, and Link State Acknowledgment packets is almost identical to the IPv4 procedures documented in Sections 10.6, 10.7, and 13.7 of [OSPFV2] respectively with the exceptions noted below. o LSAs with unknown LS types in Database Description packets that have an acceptable flooding scope are processed the same as LSAs with known LS types. In OSPFv2 [OSPF], these would result in the adjacency being brought down with a SequenceMismatch event. The receiving of Hello packets is documented in Section 3.2.2.1 and the receiving of Link State Update packets is documented in Section 3.5.1. 3.2.2.1. Receiving Hello Packets The receive processing of Hello packets differs from Section 10.5 of [OSPFV2] in the following ways: o On all link types (e.g., broadcast, NBMA, point-to-point, etc), neighbors are identified solely by their OSPF Router ID. For all link types except virtual links, the Neighbor IP address is set to the IPv6 source address in the IPv6 header of the received OSPF Hello packet. o There is no longer a Network Mask field in the Hello packet. o The neighbor's choice of Designated Router and Backup Designated Router is now encoded as an OSPF Router ID instead of an IP interface address. Coltun, et al. Expires May 19, 2008 [Page 22] Internet-Draft OSPF for IPv6 November 2007 3.3. The Routing table Structure The routing table used by OSPF for IPv4 is defined in Section 11 of [OSPFV2]. For IPv6 there are analogous routing table entries: there are routing table entries for IPv6 address prefixes and also for AS boundary routers. The latter routing table entries are only used to hold intermediate results during the routing table build process (see Section 3.8). Also, to hold the intermediate results during the shortest-path calculation for each area, there is a separate routing table for each area holding the following entries: o An entry for each router in the area. Routers are identified by their OSPF router ID. These routing table entries hold the set of shortest paths through a given area to a given router, which in turn allows calculation of paths to the IPv6 prefixes advertised by that router in intra-area-prefix-LSAs. If the router is also an area-border router, these entries are also used to calculate paths for inter-area address prefixes. If in addition the router is the other endpoint of a virtual link, the routing table entry describes the cost and viability of the virtual link. o An entry for each transit link in the area. Transit links have associated network-LSAs. Both the transit link and the network- LSA are identified by a combination of the Designated Router's Interface ID on the link and the Designated Router's OSPF Router ID. These routing table entries allow later calculation of paths to IP prefixes advertised for the transit link in intra-area- prefix-LSAs. The fields in the IPv4 OSPF routing table (see Section 11 of [OSPFV2]) remain valid for IPv6: Optional capabilities (routers only), path type, cost, type 2 cost, link state origin, and for each of the equal cost paths to the destination, the next hop and advertising router. For IPv6, the link-state origin field in the routing table entry is the router-LSA or network-LSA that has directly or indirectly produced the routing table entry. For example, if the routing table entry describes a route to an IPv6 prefix, the link state origin is the router-LSA or network-LSA that is listed in the body of the intra-area-prefix-LSA that has produced the route (see Appendix A.4.10). Coltun, et al. Expires May 19, 2008 [Page 23] Internet-Draft OSPF for IPv6 November 2007 3.3.1. Routing table lookup Routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4. 3.4. Link State Advertisements For IPv6, the OSPF LSA header has changed slightly, with the LS type field expanding and the Options field being moved into the body of appropriate LSAs. Also, the formats of some LSAs have changed somewhat (namely router-LSAs, network-LSAs, AS-external-LSAs, and NSSA-LSAs), while the names of other LSAs have been changed (type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area- router-LSAs respectively) and additional LSAs have been added (link- LSAs and intra-area-prefix-LSAs). Type of Service (TOS) has been removed from the OSPFv2 specification [OSPFV2], and is not encoded within OSPF for IPv6's LSAs. These changes will be described in detail in the following subsections. 3.4.1. The LSA Header In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20 byte LSA header. However, the contents of this 20 byte header have changed in IPv6. The LS age, Advertising Router, LS Sequence Number, LS checksum, and length fields within the LSA header remain unchanged, as documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1 of [OSPFV2] respectively. However, the following fields have changed for IPv6: Options The Options field has been removed from the standard 20 byte LSA header and moved into the body of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs. The size of the Options field has increased from 8 to 24 bits, and some of the bit definitions have changed (see Appendix A.2). Additionally, a separate PrefixOptions field, 8 bits in length, is attached to each prefix advertised within the body of an LSA. LS type The size of the LS type field has increased from 8 to 16 bits, with high order bit encoding the handling of unknown types and the next two bits encoding flooding scope. See Appendix A.4.2.1 for the current coding of the LS type field. Coltun, et al. Expires May 19, 2008 [Page 24] Internet-Draft OSPF for IPv6 November 2007 Link State ID Link State ID remains at 32 bits in length. However, except for network-LSAs and link-LSAs, Link State ID has shed any addressing semantics. For example, an IPv6 router originating multiple AS- external-LSAs could start by assigning the first a Link State ID of 0.0.0.1, the second a Link State ID of 0.0.0.2, and so on. Instead of the IPv4 behavior of encoding the network number within the AS-external-LSA's Link State ID, the IPv6 Link State ID simply serves as a way to differentiate multiple LSAs originated by the same router. For network-LSAs, the Link State ID is set to the Designated Router's Interface ID on the link. When a router originates a link-LSA for a given link, its Link State ID is set equal to the router's Interface ID on the link. 3.4.2. The link-state database In IPv6, as in IPv4, individual LSAs are identified by a combination of their LS type, Link State ID, and Advertising Router fields. Given two instances of an LSA, the most recent instance is determined by examining the LSAs' LS Sequence Number, using LS checksum and LS age as tiebreakers (see Section 13.1 of [OSPFV2]). In IPv6, the link-state database is split across three separate data structures. LSAs with AS flooding scope are contained within the top-level OSPF data structure (see Section 3.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes the AS-external-LSAs. LSAs with area flooding scope are contained within the appropriate area structure (see Section 3.1.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA- LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type and U-bit set to 0 and/or link-local flooding scope are contained within the appropriate interface structure (see Section 3.1.2); this includes link-LSAs. To lookup or install an LSA in the database, you first examine the LS type and the LSA's context (i.e., the area or link to which the LSA belongs). This information allows you to find the correct database of LSAs where you then search based on the LSA's type, Link State ID, and Advertising Router. 3.4.3. Originating LSAs The process of reoriginating an LSA in IPv6 is the same as in IPv4: the LSA's LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state Coltun, et al. Expires May 19, 2008 [Page 25] Internet-Draft OSPF for IPv6 November 2007 database and flooded on the appropriate interfaces. The list of events causing LSAs to be reoriginated for IPv4 is given in Section 12.4 of [OSPFV2]. The following events and/or actions are added for IPv6: o The state or interface ID of one of the router's interfaces changes. The router may need to (re)originate or flush its link- LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If the router is Designated Router, the router may also need to (re)originate and/or flush the network LSA corresponding to the interface. o The identity of a link's Designated Router changes. The router may need to (re)originate or flush the link's network-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. o A neighbor transitions to/from "Full" state. The router may need to (re)originate or flush the link's network-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. o The Interface ID of a neighbor changes. This may cause a new instance of a router-LSA to be originated for the associated area. o A new prefix is added to an attached link, or a prefix is deleted (both through configuration). This causes the router to reoriginate its link-LSA for the link or, if it is the only router attached to the link, causes the router to reoriginate an intra- area-prefix-LSA. o A new link-LSA is received, causing the link's collection of prefixes to change. If the router is Designated Router for the link, it originates a new intra-area-prefix-LSA. o A new link-LSA is received, causing the logical OR of LSA options advertised by adjacent routers on the link to change. If the router is Designated Router for the link, it originates a new network-LSA. Detailed construction of the seven required IPv6 LSA types is supplied by the following subsections. In order to display example LSAs, the network map in Figure 15 of [OSPFV2] has been reworked to show IPv6 addressing, resulting in Figure 1. The OSPF cost of each interface is has been displayed in Figure 1. The assignment of IPv6 prefixes to network links is shown in Table 1. A single area address range has been configured for Area 1, so that outside of Area 1 all of its prefixes are covered by a single route to 5f00:0000:c001::/48. Coltun, et al. Expires May 19, 2008 [Page 26] Internet-Draft OSPF for IPv6 November 2007 The OSPF interface IDs and the link-local addresses for the router interfaces in Figure 1 are given in Table 2. Coltun, et al. Expires May 19, 2008 [Page 27] Internet-Draft OSPF for IPv6 November 2007 .......................................... . Area 1. . + . . | . . | 3+---+1 . . N1 |--|RT1|-----+ . . | +---+ \ . . | \ ______ . . + \/ \ 1+---+ . * N3 *------|RT4|------ . + /\_______/ +---+ . | / | . . | 3+---+1 / | . . N2 |--|RT2|-----+ 1| . . | +---+ +---+ . . | |RT3|---------------- . + +---+ . . |2 . . | . . +------------+ . . N4 . .......................................... Figure 1: Area 1 with IP addresses shown Network IPv6 prefix ----------------------------------- N1 5f00:0000:c001:0200::/56 N2 5f00:0000:c001:0300::/56 N3 5f00:0000:c001:0100::/56 N4 5f00:0000:c001:0400::/56 Table 1: IPv6 link prefixes for sample network Router Interface Interface ID link-local address ------------------------------------------------------- RT1 to N1 1 fe80:0001::RT1 to N3 2 fe80:0002::RT1 RT2 to N2 1 fe80:0001::RT2 to N3 2 fe80:0002::RT2 RT3 to N3 1 fe80:0001::RT3 to N4 2 fe80:0002::RT3 RT4 to N3 1 fe80:0001::RT4 Table 2: OSPF Interface IDs and link-local addresses Coltun, et al. Expires May 19, 2008 [Page 28] Internet-Draft OSPF for IPv6 November 2007 Figure 1 3.4.3.1. LSA Options The Options field in LSAs should be coded as follows. The V6-bit should be set unless the router will not participate in transit IPv6 routing. The E-bit should be clear if and only if the attached area is an OSPF stub or OSPF NSSA area. The E-bit should always be set in AS scoped LSAs. The N-bit should be set if and only if the attached area is an OSPF NSSA area. The R-bit should be set unless the router will not participate in any transit routing. The DC-bit should be set if and only if the router can correctly process the DoNotAge bit when it appears in the LS age field of LSAs (see [DEMAND]). All unrecognized bits in the Options field should be cleared. The V6-bit and R-bit are only examined in Router-LSAs during the SPF computation. In other LSA types containing options, they are set for informational purposes only. 3.4.3.2. Router-LSAs The LS type of a router-LSA is set to the value 0x2001. Router-LSAs have area flooding scope. A router MAY originate one or more router- LSAs for a given area. Each router-LSA contains an integral number of interface descriptions. Taken together, the collection of router- LSAs originated by the router for an area describes the collected states of all the router's interfaces attached to the area. When multiple router-LSAs are used, they are distinguished by their Link State ID fields. To the left of the Options field, the router capability bits V, E, and B should be set according to Section 12.4.1 of [OSPFV2]. Each of the router's interfaces to the area are then described by appending "link descriptions" to the router-LSA. Each link description is 16 bytes long, consisting of 5 fields: (link) Type, Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID (see Appendix A.4.3). Interfaces in state "Down" or "Loopback" are not described (although looped back interfaces can contribute prefixes to intra-area-prefix-LSAs). Nor are interfaces without any full adjacencies described (except in the case of multiple standby interfaces as described in Section 3.9). All other interfaces to the area add zero, one, or more link descriptions. The number and content of these depend on the interface type. Within each link description, the Metric field is always set to the interface's output cost and the Interface ID field is set to the interface's OSPF Interface ID. Coltun, et al. Expires May 19, 2008 [Page 29] Internet-Draft OSPF for IPv6 November 2007 Point-to-point interfaces If the neighboring router is fully adjacent, add a Type 1 link description (point-to-point). The Neighbor Interface ID field is set to the Interface ID advertised by the neighbor in its Hello packets and the Neighbor Router ID field is set to the neighbor's Router ID. Broadcast and NBMA interfaces If the router is fully adjacent to the link's Designated Router or if the router itself is Designated Router and is fully adjacent to at least one other router, add a single Type 2 link description (transit network). The Neighbor Interface ID field is set to the Interface ID advertised by the Designated Router in its Hello packets and the Neighbor Router ID field is set to the Designated Router's Router ID. Virtual links If the neighboring router is fully adjacent, add a Type 4 link description (virtual). The Neighbor Interface ID field is set to the Interface ID advertised by the neighbor in its Hello packets and the Neighbor Router ID field is set to the neighbor's Router ID. Note that the output cost of a virtual link is calculated during the routing table calculation (see Section 3.7). Point-to-Multipoint interfaces For each fully adjacent neighbor associated with the interface, add a separate Type 1 link description (point-to-point) with Neighbor Interface ID field set to the Interface ID advertised by the neighbor in its Hello packets and Neighbor Router ID field set to the neighbor's Router ID. As an example, consider the router-LSA that router RT3 would originate for Area 1 in Figure 1. Only a single interface must be described, namely that which connects to the transit network N3. It assumes that RT4 has been elected Designated Router of Network N3. Coltun, et al. Expires May 19, 2008 [Page 30] Internet-Draft OSPF for IPv6 November 2007 ; RT3's router-LSA for Area 1 LS age = 0 ;newly (re)originated LS type = 0x2001 ;router-LSA Link State ID = 0 ;first fragment Advertising Router = 192.1.1.3 ;RT3's Router ID bit E = 0 ;not an AS boundary router bit B = 1 ;area border router Options = (V6-bit|E-bit|R-bit) Type = 2 ;connects to N3 Metric = 1 ;cost to N3 Interface ID = 1 ;RT3's Interface ID on N3 Neighbor Interface ID = 1 ;RT4's Interface ID on N3 Neighbor Router ID = 192.1.1.4 ; RT4's Router ID RT3's router-LSA for Area 1 For example, if another router was added to Network N4, RT3 would have to advertise a second link description for its connection to (the now transit) network N4. This could be accomplished by reoriginating the above router-LSA, this time with two link descriptions. Or, a separate router-LSA could be originated with a separate Link State ID (e.g., using a Link State ID of 1) to describe the connection to N4. Host routes for stub networks no longer appear in the router-LSA. Rather, they are included in intra-area-prefix-LSAs. 3.4.3.3. Network-LSAs The LS type of a network-LSA is set to the value 0x2002. Network- LSAs have area flooding scope. A network-LSA is originated for every broadcast or NBMA link with an elected Designated Router that is fully adjacent with at least one other router on the link. The network-LSA is originated by the link's Designated Router and lists all routers on the link with whom it is fully adjacent. The procedure for originating network-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.2 of [OSPFV2], with the following exceptions: o An IPv6 network-LSA's Link State ID is set to the Interface ID of the Designated Router on the link. o IPv6 network-LSAs do not contain a Network Mask. All addressing information formerly contained in the IPv4 network-LSA has now been consigned to intra-Area-Prefix-LSAs originated by the link's Coltun, et al. Expires May 19, 2008 [Page 31] Internet-Draft OSPF for IPv6 November 2007 Designated Router. o The Options field in the network-LSA is set to the logical OR of the Options fields contained within the link's associated link- LSAs corresponding to fully adjacent neighbors. In this way, the network link exhibits a capability when at least one fully adjacent neighbor on the link requests that the capability be advertised. As an example, assuming that Router RT4 has been elected Designated Router of Network N3 in Figure 1, the following network-LSA is originated: ; Network-LSA for Network N3 LS age = 0 ;newly (re)originated LS type = 0x2002 ;network-LSA Link State ID = 1 ;RT4's Interface ID on N3 Advertising Router = 192.1.1.4 ;RT4's Router ID Options = (V6-bit|E-bit|R-bit) Attached Router = 192.1.1.4 ;Router ID Attached Router = 192.1.1.1 ;Router ID Attached Router = 192.1.1.2 ;Router ID Attached Router = 192.1.1.3 ;Router ID Network-LSA for Network N3 3.4.3.4. Inter-Area-Prefix-LSAs The LS type of an inter-area-prefix-LSA is set to the value 0x2003. Inter-area-prefix-LSAs have area flooding scope. In IPv4, inter- area-prefix-LSAs were called type 3 summary-LSAs. Each inter-area- prefix-LSA describes a prefix external to the area yet internal to the Autonomous System. The procedure for originating inter-area-prefix-LSAs in IPv6 is the same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1 of [OSPFV2], with the following exceptions: o The Link State ID of an inter-area-prefix-LSA has lost all of its addressing semantics and simply serves to distinguish multiple inter-area-prefix-LSAs that are originated by the same router. o The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified. Coltun, et al. Expires May 19, 2008 [Page 32] Internet-Draft OSPF for IPv6 November 2007 o The NU-bit in the PrefixOptions field should be clear. o Link-local addresses MUST never be advertised in inter-area- prefix-LSAs. As an example, the following shows the inter-area-prefix-LSA that Router RT4 originates into the OSPF backbone area, condensing all of Area 1's prefixes into the single prefix 5f00:0000:c001::/48. The cost is set to 4, which is the maximum cost of all of the individual component prefixes. The prefix is padded out to an even number of 32-bit words, so that it consumes 64-bits of space instead of 48 bits. ; Inter-area-prefix-LSA for Area 1 addresses ; originated by Router RT4 into the backbone LS age = 0 ;newly (re)originated LS type = 0x2003 ;inter-area-prefix-LSA Advertising Router = 192.1.1.4 ;RT4's ID Metric = 4 ;maximum to components PrefixLength = 48 PrefixOptions = 0 Address Prefix = 5f00:0000:c001 ;padded to 64-bits Inter-area-prefix-LSA for Area 1 addresses originated by Router RT4 into the backbone 3.4.3.5. Inter-Area-Router-LSAs The LS type of an inter-area-router-LSA is set to the value 0x2004. Inter-area-router-LSAs have area flooding scope. In IPv4, inter- area-router-LSAs were called type 4 summary-LSAs. Each inter-area- router-LSA describes a path to a destination OSPF router (an AS Boundary Router or ASBR) that is external to the area yet internal to the Autonomous System. The procedure for originating inter-area-router-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.3 of [OSPFV2], with the following exceptions: o The Link State ID of an inter-area-router-LSA is no longer the destination router's OSPF Router ID and now simply serves to distinguish multiple inter-area-router-LSAs that are originated by the same router. The destination router's Router ID is now found in the body of the LSA. Coltun, et al. Expires May 19, 2008 [Page 33] Internet-Draft OSPF for IPv6 November 2007 o The Options field in an inter-area-router-LSA should be set equal to the Options field contained in the destination router's own router-LSA. The Options field thus describes the capabilities supported by the destination router. As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2]. Router RT4 would originate into Area 1 the following inter-area-router-LSA for destination router RT7. ; inter-area-router-LSA for AS boundary router RT7 ; originated by Router RT4 into Area 1 LS age = 0 ;newly (re)originated LS type = 0x2004 ;inter-area-router-LSA Advertising Router = 192.1.1.4 ;RT4's ID Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities Metric = 14 ;cost to RT7 Destination Router ID = Router RT7's ID Inter-area-router-LSA for AS boundary router RT7 originated by Router RT4 into Area 1 3.4.3.6. AS-external-LSAs The LS type of an AS-external-LSA is set to the value 0x4005. AS- external-LSAs have AS flooding scope. Each AS-external-LSA describes a path to a prefix external to the Autonomous System. The procedure for originating AS-external-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.4 of [OSPFV2], with the following exceptions: o The Link State ID of an AS-external-LSA has lost all of its addressing semantics and simply serves to distinguish multiple AS- external-LSAs that are originated by the same router. o The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified. o The NU-bit in the PrefixOptions field should be clear. o Link-local addresses can never be advertised in AS-external-LSAs. o The forwarding address is present in the AS-external-LSA if and only if the AS-external-LSA's bit F is set. Coltun, et al. Expires May 19, 2008 [Page 34] Internet-Draft OSPF for IPv6 November 2007 o The external route tag is present in the AS-external-LSA if and only if the AS-external-LSA's bit T is set. o The capability for an AS-external-LSA to reference another LSA has been supported through the inclusion of the Referenced LS Type field and the optional Referenced Link State ID field (the latter present if and only if Referenced LS Type is non-zero). This capability is for future use; Referenced LS Type should be set to 0 and received non-zero values for this field should be ignored until its use is defined. As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2]. Assume that RT7 has learned its route to N12 via BGP, and that it wishes to advertise a Type 2 metric into the AS. Also assume that the IPv6 prefix for N12 is the value 5f00:0000:0a00::/40. RT7 would then originate the following AS-external-LSA for the external network N12. Note that within the AS-external-LSA, N12's prefix occupies 64 bits of space in order to maintain 32-bit alignment. ; AS-external-LSA for Network N12, ; originated by Router RT7 LS age = 0 ;newly (re)originated LS type = 0x4005 ;AS-external-LSA Link State ID = 123 ;or something else Advertising Router = Router RT7's ID bit E = 1 ;Type 2 metric bit F = 0 ;no forwarding address bit T = 1 ;external route tag included Metric = 2 PrefixLength = 40 PrefixOptions = 0 Referenced LS Type = 0 ;no Referenced Link State ID Address Prefix = 5f00:0000:0a00 ;padded to 64-bits External Route Tag = as per BGP/OSPF interaction AS-external-LSA for Network N12, originated by Router RT7 3.4.3.7. NSSA-LSAs The LS type of an NSSA-LSA is set to the value 0x2005. NSSA-LSAs have area flooding scope. Each NSSA-LSA describes a path to a prefix external to the Autonomous System whose flooding scope is restricted to a single NSSA area. The procedure for originating NSSA-LSAs in IPv6 is the same as the IPv4 procedure documented in [NSSA], with the following exceptions: Coltun, et al. Expires May 19, 2008 [Page 35] Internet-Draft OSPF for IPv6 November 2007 o The Link State ID of an NSSA-LSA has lost all of its addressing semantics and simply serves to distinguish multiple NSSA-LSAs that are originated by the same router in the same area. o The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified. o The NU-bit in the PrefixOptions field should be clear. o Link-local addresses can never be advertised in NSSA-LSAs. o The forwarding address is present in the NSSA-LSA if and only if the NSSA-LSA's bit F is set. o The external route tag is present in the NSSA-LSA if and only if the NSSA-LSA's bit T is set. o The capability for an NSSA-LSA to reference another LSA has been supported through the inclusion of the Referenced LS Type field and the optional Referenced Link State ID field (the latter present if and only if Referenced LS Type is non-zero). This capability is for future use; Referenced LS Type should be set to 0 and received non-zero values for this field should be ignored until its use is defined. An example of an NSSA-LSA would only differ from an AS-external-LSA in that the LS type would be 0x2007 rather than 0x4005. 3.4.3.8. Link-LSAs The LS type of a link-LSA is set to the value 0x0008. Link-LSAs have link-local flooding scope. A router originates a separate link-LSA for each attached link that supports 2 or more (including the originating router itself) routers. Link-LSAs SHOULD NOT be originated for virtual links. Link-LSAs have three purposes: 1. They provide the router's link-local address to all other routers attached to the link. 2. They inform other routers attached to the link of a list of IPv6 prefixes to associate with the link. 3. They allow the router to advertise a collection of Options bits in the network-LSA originated by the Designated Router on a Coltun, et al. Expires May 19, 2008 [Page 36] Internet-Draft OSPF for IPv6 November 2007 broadcast or NBMA link. A link-LSA for a given Link L is built in the following fashion: o The Link State ID is set to the router's Interface ID on Link L. o The Router Priority of the router's interface to Link L is inserted into the link-LSA. o The link-LSA's Options field is set to those bits that the router wishes set in Link L's Network LSA. o The router inserts its link-local address on Link L into the link- LSA. This information will be used when the other routers on Link L do their next hop calculations (see Section 3.8.2). o Each IPv6 address prefix that has been configured on Link L is added to the link-LSA by specifying values for PrefixLength, PrefixOptions, and Address Prefix fields. After building a link-LSA for a given link, the router installs the link-LSA into the associated interface data structure and floods the link-LSA on the link. All other routers on the link will receive the link-LSA but they will not flood the link-LSA on other links. If LinkLSASuppression is configured for the interface and the interface type is not broadcast or NBMA, origination of the Link-LSA may be suppressed. This implies that other routers on the link will ascertain the router's next-hop address using a mechanism other than the Link-LSA (see Section 3.8.2). Refer to Appendix C.3 for a description of the LinkLSASuppression interface configuration parameter. As an example, consider the link-LSA that RT3 will build for N3 in Figure 1. Suppose that the prefix 5f00:0000:c001:0100::/56 has been configured within RT3 for N3. This will result in the following link-LSA that RT3 will flood only on N3. Note that not all routers on N3 need be configured with the prefix; those not configured will learn the prefix when receiving RT3's link-LSA. Coltun, et al. Expires May 19, 2008 [Page 37] Internet-Draft OSPF for IPv6 November 2007 ; RT3's link-LSA for N3 LS age = 0 ;newly (re)originated LS type = 0x0008 ;Link-LSA Link State ID = 1 ;RT3's Interface ID on N3 Advertising Router = 192.1.1.3 ;RT3's Router ID Rtr Priority = 1 ;RT3's N3 Router Priority Options = (V6-bit|E-bit|R-bit) Link-local Interface Address = fe80:0001::RT3 # prefixes = 1 PrefixLength = 56 PrefixOptions = 0 Address Prefix = 5f00:0000:c001:0100 ;pad to 64-bits RT3's link-LSA for N3 3.4.3.9. Intra-Area-Prefix-LSAs The LS type of an intra-area-prefix-LSA is set to the value 0x2009. Intra-area-prefix-LSAs have area flooding scope. An intra-area- prefix-LSA has one of two functions. It either associates a list of IPv6 address prefixes with a transit network link by referencing a network-LSA, or associates a list of IPv6 address prefixes with a router by referencing a router-LSA. A stub link's prefixes are associated with its attached router. A router MAY originate multiple intra-area-prefix-LSAs for a given area. Each intra-area-prefix-LSA has a unique Link-State ID and contains an integral number of prefix descriptions. A link's Designated Router originates one or more intra-area-prefix- LSAs to advertise the link's prefixes throughout the area. For a link L, L's Designated Router builds an intra-area-prefix-LSA in the following fashion: o In order to indicate that the prefixes are to be associated with the Link L, the fields Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router are set to the corresponding fields in Link L's network-LSA (namely LS type, Link State ID, and Advertising Router respectively). This means that Referenced LS Type is set to 0x2002, Referenced Link State ID is set to the Designated Router's Interface ID on Link L, and Referenced Advertising Router is set to the Designated Router's Router ID. o Each link-LSA associated with Link L is examined (these are in the Designated Router's interface structure for Link L). If the link- LSA's Advertising Router is fully adjacent to the Designated Coltun, et al. Expires May 19, 2008 [Page 38] Internet-Draft OSPF for IPv6 November 2007 Router and the Link State ID matches the neighbor's interface ID, the list of prefixes in the link-LSA is copied into the intra- area-prefix-LSA that is being built. Prefixes having the NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, nor should link-local addresses be copied. Each prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields. Multiple prefixes having the same PrefixLength and Address Prefix are considered to be duplicates. In this case their Prefix Options fields should be logically OR'ed together and a single instance of the duplicate prefix should be included in the intra- area-prefix-LSA. The Metric field for all prefixes is set to 0. o The "# prefixes" field is set to the number of prefixes that the router has copied into the LSA. If necessary, the list of prefixes can be spread across multiple intra-area-prefix-LSAs in order to keep the LSA size small. A router builds an intra-area-prefix-LSA to advertise prefixes for its attached stub links, looped back interfaces, and hosts. A Router RTX would build its intra-area-prefix-LSA in the following fashion: o In order to indicate that the prefixes are to be associated with the Router RTX itself, RTX sets Referenced LS Type to 0x2001, Referenced Link State ID to 0, and Referenced Advertising Router to RTX's own Router ID. o Router RTX examines its list of interfaces to the area. If the interface is in state Down, its prefixes are not included. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), prefixes which will be included in the intra-area-prefix-LSA for the link are skipped. However, any prefixes which would normally have the LA-bit set SHOULD be advertised independent of whether or not the interface is advertised as a transit link. If the interface type is Point- to-Multipoint or the interface is in state Loopback, the global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area-prefix-LSA with the PrefixOptions LA- bit set, the PrefixLength set to 128, and the metric set to 0. Otherwise, the list of global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the interface's output cost. o RTX adds the IPv6 prefixes for any directly attached hosts belonging to the area (see Appendix C.7) to the intra-area-prefix- LSA. Coltun, et al. Expires May 19, 2008 [Page 39] Internet-Draft OSPF for IPv6 November 2007 o If RTX has one or more virtual links configured through the area, it includes one of its global scope IPv6 interface addresses in the LSA (if it hasn't already), setting the LA-bit in the PrefixOptions field, the PrefixLength to 128, and the Metric to 0. This information will be used later in the routing calculation so that the two ends of the virtual link can discover each other's IPv6 addresses. o The "# prefixes" field is set to the number of prefixes that the router has copied into the LSA. If necessary, the list of prefixes can be spread across multiple intra-area-prefix-LSAs in order to keep the LSA size small. For example, the intra-area-prefix-LSA originated by RT4 for Network N3 (assuming that RT4 is N3's Designated Router), and the intra-area- prefix-LSA originated into Area 1 by Router RT3 for its own prefixes, are pictured below. ; RT4's Intra-area-prefix-LSA for network link N3 LS age = 0 ;newly (re)originated LS type = 0x2009 ;Intra-area-prefix-LSA Link State ID = 5 ;or something Advertising Router = 192.1.1.4 ;RT4's Router ID # prefixes = 1 Referenced LS Type = 0x2002 ;network-LSA reference Referenced Link State ID = 1 Referenced Advertising Router = 192.1.1.4 PrefixLength = 56 ;N3's prefix PrefixOptions = 0 Metric = 0 Address Prefix = 5f00:0000:c001:0100 ;pad ; RT3's Intra-area-prefix-LSA for its own prefixes LS age = 0 ;newly (re)originated LS type = 0x2009 ;Intra-area-prefix-LSA Link State ID = 177 ;or something Advertising Router = 192.1.1.3 ;RT3's Router ID # prefixes = 1 Referenced LS Type = 0x2001 ;router-LSA reference Referenced Link State ID = 0 Referenced Advertising Router = 192.1.1.3 PrefixLength = 56 ;N4's prefix PrefixOptions = 0 Metric = 2 ;N4 interface cost Address Prefix = 5f00:0000:c001:0400 ;pad Coltun, et al. Expires May 19, 2008 [Page 40] Internet-Draft OSPF for IPv6 November 2007 Intra-area-prefix-LSA for network link N3 When network conditions change, it may be necessary for a router to move prefixes from one intra-area-prefix-LSA to another. For example, if the router is Designated Router for a link but the link has no other attached routers, the link's prefixes are advertised in an intra-area-prefix-LSA referring to the Designated Router's router- LSA. When additional routers appear on the link, a network-LSA is originated for the link and the link's prefixes are moved to an intra-area-prefix-LSA referring to the network-LSA. Note that in the intra-area-prefix-LSA, the "Referenced Advertising Router" is always equal to the router that is originating the intra- area-prefix-LSA (i.e., the LSA's Advertising Router). The reason that the Referenced Advertising Router field appears is that, even though it is currently redundant, it may not be in the future. We may sometime want to use the same LSA format to advertise address prefixes for other protocol suites. In this case, the Designated Router may not be running the other protocol suite, and so another of the link's routers may need to originate the intra-area-prefix-LSA. In that case, "Referenced Advertising Router" and "Advertising Router" would be different. 3.4.4. Future LSA Validation It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 3.8. For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In general, the new information advertised in future LSAs should not be used unless the OSPFv3 router originating the LSA is reachable. However, depending on the application and the data advertised, this reachability validation MAY be done less frequently than every SPF calculation. To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR). 3.5. Flooding Most of the flooding algorithm remains unchanged from the IPv4 flooding mechanisms described in Section 13 of [OSPFV2]. In particular, the protocol processes for determining which LSA instance is newer (Section 13.1 of [OSPFV2]), responding to updates of self- originated LSAs (Section 13.4 of [OSPFV2]), sending Link State Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting LSAs (Section 13.6 of [OSPFV2]), and receiving Link State Coltun, et al. Expires May 19, 2008 [Page 41] Internet-Draft OSPF for IPv6 November 2007 Acknowledgment packets (Section 13.7 of [OSPFV2]) are exactly the same for IPv6 and IPv4. However, the addition of flooding scope and unknown LSA type handling (see Appendix A.4.2.1) has caused some changes in the OSPF flooding algorithm: the reception of Link State Updates (Section 13 in [OSPFV2]) and the sending of Link State Updates (Section 13.3 of [OSPFV2]) must take into account the LSA's scope and U-bit setting. Also, installation of LSAs into the OSPF database (Section 13.2 of [OSPFV2]) causes different events in IPv6, due to the reorganization of LSA types and the IPv6 LSA contents. These changes are described in detail below. 3.5.1. Receiving Link State Update packets The encoding of flooding scope in the LS type and the need to process unknown LS types causes modifications to the processing of received Link State Update packets. As in IPv4, each LSA in a received Link State Update packet is examined. In IPv4, eight steps are executed for each LSA, as described in Section 13 of [OSPFV2]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows: (2) Examine the LSA's LS type. Discard the LSA and get the next one from the Link State Update packet if the interface area has been configured as a stub or NSSA area and the LS type indicates "AS flooding scope". This generalizes the IPv4 behavior where AS-external-LSAs and AS-scoped opaque LSAs [OPAQUE] are not flooded throughout stub or NSSA areas. (3) Else if the flooding scope in the LSA's LS type is set to "reserved", discard the LSA and get the next one from the Link State Update packet. Steps 5b (sending Link State Update packets) and 5d (installing LSAs in the link-state database) in Section 13 of [OSPFV2] are also somewhat different for IPv6, as described in Sections 3.5.2 and 3.5.3 below. 3.5.2. Sending Link State Update packets The sending of Link State Update packets is described in Section 13.3 of [OSPFV2]. For IPv4 and IPv6, the steps for sending a Link State Update packet are the same (steps 1 through 5 of Section 13.3 in [OSPFV2]). However, the list of eligible interfaces on which to Coltun, et al. Expires May 19, 2008 [Page 42] Internet-Draft OSPF for IPv6 November 2007 flood the LSA is different. For IPv6, the eligible interfaces are selected based on the following factors: o The LSA's flooding scope. o For LSAs with area or link-local flooding scoping, the particular area or interface that the LSA is associated with. o Whether the LSA has a recognized LS type. o The setting of the U-bit in the LS type. If the U-bit is set to 0, unrecognized LS types are treated as having link-local scope. If set to 1, unrecognized LS types are stored and flooded as if they were recognized. Choosing the set of eligible interfaces then breaks into the following cases: Case 1 The LSA's LS type is recognized. In this case, the set of eligible interfaces is set depending on the flooding scope encoded in the LS type. If the flooding scope is "AS flooding scope", the eligible interfaces are all router interfaces excepting virtual links. In addition, AS-external-LSAs are not flooded on interfaces connecting to stub or NSSA areas. If the flooding scope is "area flooding scope", the set of eligible interfaces are those interfaces connecting to the LSA's associated area. If the flooding scope is "link-local flooding scope", then there is a single eligible interface, the one connecting to the LSA's associated link (which is also the interface on which the LSA was received in a Link State Update packet). Case 2 The LS type is unrecognized and the U-bit in the LS Type is set to 0 (treat the LSA as if it had link-local flooding scope). In this case there is a single eligible interface, namely, the interface on which the LSA was received. Case 3 The LS type is unrecognized, and the U-bit in the LS Type is set to 1 (store and flood the LSA as if the type understood). In this case, select the eligible interfaces based on the encoded flooding scope the same as in Case 1 above. A further decision must sometimes be made before adding an LSA to a given neighbor's link-state retransmission list (Step 1d in Section Coltun, et al. Expires May 19, 2008 [Page 43] Internet-Draft OSPF for IPv6 November 2007 13.3 of [OSPFV2]). If the LS type is recognized by the router, but not by the neighbor (as can be determined by examining the Options field that the neighbor advertised in its Database Description packet) and the LSA's U-bit is set to 0, then the LSA should be added to the neighbor's link-state retransmission list if and only if that neighbor is the Designated Router or Backup Designated Router for the attached link. The LS types described in detail by this document, namely router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter- area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra- Area-Prefix-LSAs (0x2009) are assumed to be understood by all routers. However, all LS types MAY not be understood by all routers. For example, a new LSA type with its U-bit set to 0 MAY only be understood by a subset of routers. This new LS Type should only be flooded to an OSPF neighbor that understands the LS type or when the neighbor is Designated Router or Backup Designated Router for the attached link. The previous paragraph solves a problem for IPv4 OSPF extensions, which require that the Designated Router support the extension in order to have the new LSA types flooded across broadcast and NBMA networks. 3.5.3. Installing LSAs in the database There are three separate places to store LSAs, depending on their flooding scope. LSAs with AS flooding scope are stored in the global OSPF data structure (see Section 3.1) as long as their LS type is known or their U-bit is 1. LSAs with area flooding scope are stored in the appropriate area data structure (see Section 3.1.1) as long as their LS type is known or their U-bit is 1. LSAs with link-local flooding scope, and those LSAs with unknown LS type and U-bit set to 0 (treat the LSA as if it had link-local flooding scope) are stored in the appropriate interface data structure. When storing the LSA into the link-state database, a check must be made to see whether the LSA's contents have changed. Changes in contents are indicated exactly as in Section 13.2 of [OSPFV2]. When an LSA's contents have been changed, the following parts of the routing table must be recalculated, based on the LSA's LS type: Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs The entire routing table is recalculated, starting with the shortest path calculation for each area (see Section 3.8). Coltun, et al. Expires May 19, 2008 [Page 44] Internet-Draft OSPF for IPv6 November 2007 Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs The best route to the destination described by the LSA must be recalculated (see Section 16.5 in [OSPFV2]). If this destination is an AS boundary router, it may also be necessary to re-examine all the AS-external-LSAs. AS-external-LSAs and NSSA-LSAs The best route to the destination described by the AS-external-LSA or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and Section 2.0 in [NSSA]). As in IPv4, any old instance of the LSA must be removed from the database when the new LSA is installed. This old instance must also be removed from all neighbors' link state retransmission lists. 3.6. Definition of self-originated LSAs In IPv6 the definition of a self-originated LSA has been simplified from the IPv4 definition appearing in Sections 13.4 and 14.1 of [OSPFV2]. For IPv6, self-originated LSAs are those LSAs whose Advertising Router is equal to the router's own Router ID. 3.7. Virtual links OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2]. Virtual links are the same in IPv6, with the following exceptions: o LSAs having AS flooding scope are never flooded over virtual adjacencies, nor are LSAs with AS flooding scope summarized over virtual adjacencies during the database exchange process. This is a generalization of the IPv4 treatment of AS-external-LSAs. o The IPv6 interface address of a virtual link MUST be an IPv6 address having global scope, instead of the link-local addresses used by other interface types. This address is used as the IPv6 source for OSPF protocol packets sent over the virtual link. Hence, a Link-LSA SHOULD NOT be originated for a virtual link since the virtual link has no link-local address or associated prefixes. o Likewise, the virtual neighbor's IPv6 address is an IPv6 address with global scope. To enable the discovery of a virtual neighbor's IPv6 address during the routing calculation, the neighbor advertises its virtual link's IPv6 interface address in an intra-area-prefix-LSA originated for the virtual link's transit area (see Section 3.4.3.9 and Section 3.8.1). Coltun, et al. Expires May 19, 2008 [Page 45] Internet-Draft OSPF for IPv6 November 2007 o Like all other IPv6 OSPF interfaces, virtual links are assigned unique (within the router) Interface IDs. These are advertised in Hellos sent over the virtual link and in the router's router-LSAs. 3.8. Routing table calculation The IPv6 OSPF routing calculation proceeds along the same lines as the IPv4 OSPF routing calculation, following the five steps specified by Section 16 of [OSPFV2]. High level differences between the IPv6 and IPv4 calculations include: o Prefix information has been removed from router-LSAs and network- LSAs and is now advertised in intra-area-prefix-LSAs. Whenever [OSPFV2] specifies that stub networks within router-LSAs be examined, IPv6 will instead examine prefixes within intra-area- prefix-LSAs. o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs and inter-area-router-LSAs respectively. o Addressing information is no longer encoded in Link State IDs and is now only found within the body of LSAs. o In IPv6, a router can originate multiple router-LSAs, distinguished by Link State ID, within a single area. These router-LSAs MUST be treated as a single aggregate by the area's shortest path calculation (see Section 3.8.1). For each area, the shortest-path tree calculation creates routing table entries for the area's routers and transit links (see Section 3.8.1). These entries are then used when processing intra- area-prefix-LSAs, inter-area-prefix-LSAs, and inter-area-router-LSAs, as described in Section 3.8.3. Events generated as a result of routing table changes (Section 16.7 of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of [OSPFV2]) are identical for both IPv4 and IPv6. 3.8.1. Calculating the shortest path tree for an area The IPv4 shortest path calculation is contained in Section 16.1 of [OSPFV2]. The graph used by the shortest-path tree calculation is identical for both IPv4 and IPv6. The graph's vertices are routers and transit links, represented by router-LSAs and network-LSAs respectively. A router is identified by its OSPF Router ID, while a transit link is identified by its Designated Router's Interface ID and OSPF Router ID. Both routers and transit links have associated Coltun, et al. Expires May 19, 2008 [Page 46] Internet-Draft OSPF for IPv6 November 2007 routing table entries within the area (see Section 3.3). Section 16.1 of [OSPFV2] splits up the shortest path calculations into two stages. First the Dijkstra calculation is performed and then the stub links are added onto the tree as leaves. The IPv6 calculation maintains this split. The Dijkstra calculation for IPv6 is identical to that specified for IPv4, with the following exceptions (referencing the steps from the Dijkstra calculation as described in Section 16.1 of [OSPFV2]): o The Vertex ID for a router is the OSPF Router ID. The Vertex ID for a transit network is a combination of the Interface ID and OSPF Router ID of the network's Designated Router. o In Step 2, when a router Vertex V has just been added to the shortest path tree, there may be multiple LSAs associated with the router. All router-LSAs with Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the router type bits (bits W, V, E, and B) should always be taken from router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. o In Step 2b, if W is a router and the router LSA V6-bit or R-bit are not set in the LSA options, the transit link W is ignored and V's next link is examined. o In Step 2b, if W is a router, there may again be multiple LSAs associated with the router. All router-LSAs with Advertising Router set to W's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router- LSA. o In Step 4, there are now per-area routing table entries for each of an area's routers rather than just the area border routers. These entries subsume all the functionality of IPv4's area border router routing table entries, including the maintenance of virtual links. When the router added to the area routing table in this step is the other end of a virtual link, the virtual neighbor's IP address is set as follows: The collection of intra-area-prefix- LSAs originated by the virtual neighbor is examined, with the virtual neighbor's IP address being set to the first prefix encountered with the "LA-bit" set. Coltun, et al. Expires May 19, 2008 [Page 47] Internet-Draft OSPF for IPv6 November 2007 o Routing table entries for transit networks, which are no longer associated with IP networks, are also calculated in Step 4 and added to the per-area routing table. The next stage of the shortest path calculation proceeds similarly to the two steps of the second stage of Section 16.1 in [OSPFV2]. However, instead of examining the stub links within router-LSAs, the list of the area's intra-area-prefix-LSAs is examined. A prefix advertisement whose "NU-bit" is set SHOULD NOT be included in the routing calculation. The cost of any advertised prefix is the sum of the prefix's advertised metric plus the cost to the transit vertex (either router or transit network) identified by intra-area-prefix- LSA's Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router fields. This latter cost is stored in the transit vertex's routing table entry for the area. This specification does not require that the above algorithm be used to calculate the intra-area shortest path tree. However, if another algorithm or optimization is used, an identical shortest path tree must be produced. It is also important that any alternate algorithm or optimization maintain the requirement that transit vertices must be bidirectional for inclusion in the tree. Alternate algorithms and optimizations are beyond the scope of this specification. 3.8.2. The next hop calculation In IPv6, the calculation of the next hop's IPv6 address (which will be a link-local address) proceeds along the same lines as the IPv4 next hop calculation (see Section 16.1.1 of [OSPFV2]). However, there are some differences. When calculating the next hop IPv6 address for a router (call it Router X) which shares a link with the calculating router, the calculating router assigns the next hop IPv6 address to be the link-local interface address contained in Router X's Link- LSA (see Appendix A.4.9) for the link. This procedure is necessary for some link types, for example NBMA, where the two routers need not be neighbors and might not be exchanging OSPF Hello packets. For other link types, the next hop address may be determined via the IPv6 source address in the neighbor's Hello packet. Additionally, when calculating routes for the area's intra-area- prefix-LSAs, the parent vertex can be either a router-LSA or network- LSA. This is in contrast to the second stage of the OSPFv2 intra- area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always a router-LSA. In the case where the intra-area-prefix-LSA's referenced LSA is a directly connected network-LSA, the prefixes are also considered to be directly connected. In this case, the next-hop is solely the outgoing link and no IPv6 next hop address is selected. Coltun, et al. Expires May 19, 2008 [Page 48] Internet-Draft OSPF for IPv6 November 2007 3.8.3. Calculating the inter-area routes Calculation of inter-area routes for IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.2 of [OSPFV2], with the following modifications: o The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have been changed to inter-area-prefix-LSAs and inter-area-router-LSAs respectively. o The Link State ID of the above LSA types no longer encodes the network or router described by the LSA. Instead, an address prefix is contained in the body of an inter-area-prefix-LSA and an advertised AS boundary router's OSPF Router ID is carried in the body of an inter-area-router-LSA. o Prefixes having the "NU-bit" set in their Prefix Options field should be ignored by the inter-area route calculation. When a single inter-area-prefix-LSA or inter-area-router-LSA has changed, the incremental calculations outlined in Section 16.5 of [OSPFV2] can be performed instead of recalculating the entire routing table. 3.8.4. Examining transit areas' summary-LSAs Examination of transit areas' summary-LSAs in IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.3 of [OSPFV2], modified in the same way as the IPv6 inter-area route calculation in Section 3.8.3. 3.8.5. Calculating AS external and NSSA routes The IPv6 AS external route calculation proceeds along the same lines as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 of [NSSA], with the following exceptions: o The Link State ID of the AS-external-LSA and NSSA-LSA types no longer encodes the network described by the LSA. Instead, an address prefix is contained in the body of the LSA. o The default route in AS-external-LSAs or NSSA-LSAs is advertised by a zero length prefix. o Instead of comparing the AS-external-LSA's or NSSA-LSA's Forwarding Address field to 0.0.0.0 to see whether a forwarding Coltun, et al. Expires May 19, 2008 [Page 49] Internet-Draft OSPF for IPv6 November 2007 address has been used, the bit F in the respective LSA is examined. A forwarding address is in use if and only if bit F is set. o Prefixes having the "NU-bit" set in their Prefix Options field should be ignored by the inter-area route calculation. o AS Boundary Router (ASBR) and forwarding address selection will proceed the same as if RFC1583Compatibility is disabled. Furthermore, RFC1583Compatibility is not an OSPF for IPv6 configuration parameter. Refer to Appendix C.1. When a single AS-external-LSA or NSSA-LSA has changed, the incremental calculations outlined in Section 16.6 of [OSPFV2] can be performed instead of recalculating the entire routing table. 3.9. Multiple interfaces to a single link In OSPF for IPv6, a router may have multiple interfaces to a single link associated with the same OSPF instance and area. All interfaces will be used for the reception and transmission of data traffic while only a single interface sends and receives OSPF control traffic. In more detail: o Each of the multiple interfaces are assigned different Interface IDs. A router will automatically detect that multiple interfaces are attached to the same link when a Hello packet is received with one of the router's link-local addresses as the source address and an Interface ID other than the Interface ID of the receiving interface. o Each of the multiple interfaces MUST be configured with the same Interface Instance ID to be considered on the same link. If an interface has multiple Instance IDs, it will be grouped with other interfaces based on matching Instance IDs. Each Instance ID will be treated uniquely with respect to groupings of multiple interfaces on the same link. For example, if interface A is configured with Instance IDs 1 and 35, and interface B is configured with Instance ID 35, interface B may be the Active interface for Instance ID 35 but interface A will be active for Instance ID 1. o The router will ignore OSPF packets other than Hello packets on all but one of the interfaces attached to the link. It will only send its OSPF control packets (including Hello packets) on a single interface. This interface is designated the Active Interface and other interfaces attached to the same link will be Coltun, et al. Expires May 19, 2008 [Page 50] Internet-Draft OSPF for IPv6 November 2007 designated Standby Interfaces. The choice of the Active interface is implementation dependent. For example, the interface with the highest Interface ID could be chosen. If the router is elected Designated Router, it will be the Active interface's Interface ID that will be used as the network-LSA's Link State ID. o All of the interfaces to the link (Active and Standby) will appear in the router-LSA. In addition, a link-LSA will be generated for each of the interfaces. In this way, all interfaces will be included in OSPF's routing calculations. o Any link-local scope LSAs which are originated for a Standby Interface will be flooded over the Active Interface. If a Standby Interface goes down then the link-local scope LSAs originated for the Standby Interfaces MUST be flushed on the Active Interface. o Prefixes on Standby Interfaces will be processed the same way as prefixes on the Active Interface. For example, if the router is the DR for the link, the Active Interface's prefixes are included in an intra-area-prefix-LSA which is associated with the Active Interface's network-LSA, prefixes from Standby Interfaces on the link will also be included in that intra-area-prefix LSA. Similarly, if the link is a stub link, then the prefixes for the Active and Standby Interfaces will all be included in the same intra-area-prefix-LSA that is associated with the router-LSA. o If the Active Interface fails, a new Active Interface will have to take over. The new Active Interface SHOULD form all new neighbor adjacencies with routers on the link. This failure can be detected when the router's other interfaces to the Active Interface's link cease to hear the router's Hellos or through internal mechanisms, e.g., monitoring the Active Interface's status. o If the network becomes partitioned with different local interfaces attaching to different network partitions, multiple interfaces will become Active Interfaces and function independently. o During the SPF calculation when a network-LSA for a network which is directly connected to the root vertex is being examined, all of the multiple interfaces to the link of adjacent router-LSAs must be used in the next-hop calculation. This can be accomplished during the back link check (see section 16.1 Step 2 (B) in [OSPFV2]) by examining each link of the router- LSA and making a list of the links that point to the network LSA. The Interface IDs for links in this list are then used to find the corresponding link-LSAs and the link local addresses used as next Coltun, et al. Expires May 19, 2008 [Page 51] Internet-Draft OSPF for IPv6 November 2007 hops when installing equal-cost paths in the routing table. o The interface state machine is modified to add the state Standby. See Section 3.9.1 for a description of the Standby state. 3.9.1. Standby Interface State In this state, the interface is one of multiple interfaces to a link and this interface is designated Standby and is not sending or receiving control packets. The interface will continue to receive the Hello packets sent by the Active Interface. The interface will maintain a timer, the Active Interface Timer, with the same interval as the RouterDeadInterval. This timer will be reset whenever an OSPF Hello packet is received from the Active Interface to the link. Two new events are added to the list of events which cause interface state changes: MultipleInterfacesToLink and ActiveInterfaceDead. The descriptions of these events are as follows: MultipleInterfacesToLink An interfaces on the router has received a Hello packet from another interface on the same router. One of the interfaces is designated as the Active Interface and the other interface is designated as a Standby Interface. The Standby Interface transitions to the Standby state. ActiveInterfaceDead There has been an indication that a Standby Interface is no longer on a link with an Active Interface. The firing of the Active Interface Timer is one indication of this event, as it indicates that the Standby Interface has not received an OSPF Hello packet from the Active Interface for the RouterDeadInterval. Other indications may come from internal notifications, such as the Active Interface being disabled through a configuration change. Any indication internal to the router, such that the router knows the Active Interface is no longer active on the link, can trigger the ActiveInterfaceDead event for a Standby Interface. Interface state machine additions include: Coltun, et al. Expires May 19, 2008 [Page 52] Internet-Draft OSPF for IPv6 November 2007 State(s): Waiting, DR Other, Backup or DR Event: MultipleInterfacesToLink New state: Standby Action: All interface variables are reset and interface timers disabled. Also, all neighbor connections associated with the interface are destroyed. This is done by generating the event KillNbr on all associated neighbors. The Active Interface Timer is started and the interface will listen for OSPF Hello packets from the link's Active Interface. State(s): Standby Event: ActiveInterfaceDead New state: Down Action: The Active Interface Timer is first disabled. Then the InterfaceUp event is invoked. Standby Interface State Machine Additions Coltun, et al. Expires May 19, 2008 [Page 53] Internet-Draft OSPF for IPv6 November 2007 4. Security Considerations When running over IPv6, OSPF relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) to ensure integrity and authentication/confidentiality of protocol packets. This is described in [OSPFV3-AUTH]. Coltun, et al. Expires May 19, 2008 [Page 54] Internet-Draft OSPF for IPv6 November 2007 5. IANA Considerations Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA]. Additionally, this document introduces the following IANA requirements that were not present in [OSPFV3]: o Reserve the options with the values 0x000040 and 0x000080 for migrated OSPFv2 options in the OSPFv3 Options registry defined in [OSPF-IANA]. For information on the OSPFv3 Options Field refer to Appendix A.2. o Add prefix option P-bit with value 0x08 to the OSPFv3 Prefix Options registry defined in [OSPF-IANA]. For information on OSPFv3 Prefix Options refer to Appendix A.4.1.1. o Add prefix option DN-bit with value 0x10 to the OSPFv3 Prefix Options registry defined in [OSPF-IANA]. For information on OSPFv3 Prefix Options refer to Appendix A.4.1.1. 5.1. MOSPF for OSPFv3 Deprecation IANA Considerations With the deprecation of MOSPF for OSPFv3, the following code points are available for reassignment. Refer to [OSPF-IANA] for information on the respective registries. o Deprecate the MC-bit with value 0x000004 in the OSPFv3 Options Registry. o Deprecate Group-membership-LSA with value 6 in OSPFv3 LSA Function Code Registry. o Deprecate MC-bit with value 0x04 in the OSPFv3 Prefix Options Registry. Coltun, et al. Expires May 19, 2008 [Page 55] Internet-Draft OSPF for IPv6 November 2007 6. Acknowledgments The RFC text was produced using Marshall Rose's xml2rfc tool. The following individuals contributed comments which that incorporated into this document: o Harold Rabbie for his description of protocol details which needed to be clarified for OSPFv3 NSSA support. o Nic Neate for his pointing out that there needed to be changes for unknown LSA types handling in the processing of Database Description packets. o Jacek Kwiatkowski for being the first to point out that the V6 and R bits are not taken into account in the OSPFv3 intra-area SPF calculation. o Michael Barnes recognized that the support for multiple interfaces to a single link was broken (see Section 3.9) and provided the description of the current protocol mechanisms. Abhay Roy reviewed and suggested improvements to the mechanisms. o Alan Davey reviewed and commented on draft revisions. o Vivek Dubey reviewed and commented on draft revisions. o Manoj Goyal and Vivek Dubey complained enough about link-LSAs being unnecessary to compel introduction of the LinkLSASuppression interface configuration parameter. o Manoj Goyal for pointing out that the next-hop calculation for intra-area-prefix-LSAs corresponding to network vertices was unclear. o Ramana Koppula reviewed and commented on draft revisions. o Paul Wells reviewed and commented on draft revisions. o Amir Khan reviewed and commented on draft revisions. o Dow Street and Wayne Wheeler commented on the addition of the DN bit to OSPFv3. o Mitchell Erblichs provided numerous editorial comments. Coltun, et al. Expires May 19, 2008 [Page 56] Internet-Draft OSPF for IPv6 November 2007 o Russ White provided numerous editorial comments. o Kashima Hiroaki provided editorial comments. o Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2 with respect to precedence and should map it to IPv6 traffic class as specified in RFC 2474. Steve Blake helped with the text. Coltun, et al. Expires May 19, 2008 [Page 57] Internet-Draft OSPF for IPv6 November 2007 7. References 7.1. Normative References [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. [DIFF-SERV] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [DN-BIT] Rosen, E., Peter, P., and P. Pillay-Esnault, "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs", RFC 4576, April 2005. [INTFMIB] McCloghrie, K. and F. Kastenholz, "The interfaces Group MIB using SMIv2", RFC 2233, November 1997. [IP6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [IPAUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [IPESP] Kent, S. and R. Atkinson, "IP Encapsulation Security Payload (ESP)", RFC 2406, November 1998. [IPV4] Postal, J., "Internet Protocol", RFC 791, September 1981. [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2373, December 1998. [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994. [NSSA] Murphy, P., "The OSP