TOC 
Network Working GroupR. Coltun
Internet-DraftAcoustra Productions
Obsoletes: 2740 (if approved)D. Ferguson
Intended status: Standards TrackJuniper Networks
Expires: November 14, 2008J. Moy
 Sycamore Networks, Inc
 A. Lindem (Editor)
 Redback Networks
 May 13, 2008


OSPF for IPv6
draft-ietf-ospf-ospfv3-update-23.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 November 14, 2008.

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, Short Path First (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. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF Version 3 (OSPFv3).

Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (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 (ESP).

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.



Table of Contents

1.  Introduction
    1.1.  Requirements notation
    1.2.  Terminology
2.  Differences from OSPF for IPv4
    2.1.  Protocol processing per-link, not per-subnet
    2.2.  Removal of addressing semantics
    2.3.  Addition of Flooding scope
    2.4.  Explicit support for multiple instances per link
    2.5.  Use of link-local addresses
    2.6.  Authentication changes
    2.7.  Packet format changes
    2.8.  LSA format changes
    2.9.  Handling unknown LSA types
    2.10.  Stub/NSSA area support
    2.11.  Identifying neighbors by Router ID
3.  Differences with RFC 2740
    3.1.  Support for Multiple Interfaces on the same Link
    3.2.  Deprecation of MOSPF for IPv6
    3.3.  NSSA Specification
    3.4.  Stub Area Unknown LSA Flooding Restriction Deprecated
    3.5.  Link LSA Suppression
    3.6.  LSA Options and Prefix Options Updates
    3.7.  IPv6 Site-Local Addresses
4.  Implementation details
    4.1.  Protocol data structures
        4.1.1.  The Area Data structure
        4.1.2.  The Interface Data structure
        4.1.3.  The Neighbor Data Structure
    4.2.  Protocol Packet Processing
        4.2.1.  Sending protocol packets
            4.2.1.1.  Sending Hello Packets
            4.2.1.2.  Sending Database Description Packets
        4.2.2.  Receiving Protocol Packets
            4.2.2.1.  Receiving Hello Packets
    4.3.  The Routing table Structure
        4.3.1.  Routing table lookup
    4.4.  Link State Advertisements
        4.4.1.  The LSA Header
        4.4.2.  The link-state database
        4.4.3.  Originating LSAs
            4.4.3.1.  LSA Options
            4.4.3.2.  Router-LSAs
            4.4.3.3.  Network-LSAs
            4.4.3.4.  Inter-Area-Prefix-LSAs
            4.4.3.5.  Inter-Area-Router-LSAs
            4.4.3.6.  AS-external-LSAs
            4.4.3.7.  NSSA-LSAs
            4.4.3.8.  Link-LSAs
            4.4.3.9.  Intra-Area-Prefix-LSAs
        4.4.4.  Future LSA Validation
    4.5.  Flooding
        4.5.1.  Receiving Link State Update packets
        4.5.2.  Sending Link State Update packets
        4.5.3.  Installing LSAs in the database
    4.6.  Definition of self-originated LSAs
    4.7.  Virtual links
    4.8.  Routing table calculation
        4.8.1.  Calculating the shortest path tree for an area
        4.8.2.  The next hop calculation
        4.8.3.  Calculating the inter-area routes
        4.8.4.  Examining transit areas' summary-LSAs
        4.8.5.  Calculating AS external and NSSA routes
    4.9.  Multiple interfaces to a single link
        4.9.1.  Standby Interface State
5.  Security Considerations
6.  Manageability Considerations
7.  IANA Considerations
    7.1.  MOSPF for OSPFv3 Deprecation IANA Considerations
8.  Acknowledgments
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  OSPF data formats
    A.1.  Encapsulation of OSPF packets
    A.2.  The Options field
    A.3.  OSPF Packet Formats
        A.3.1.  The OSPF packet header
        A.3.2.  The Hello Packet
        A.3.3.  The Database Description Packet
        A.3.4.  The Link State Request Packet
        A.3.5.  The Link State Update Packet
        A.3.6.  The Link State Acknowledgment Packet
    A.4.  LSA formats
        A.4.1.  IPv6 Prefix Representation
            A.4.1.1.  Prefix Options
        A.4.2.  The LSA header
            A.4.2.1.  LSA Type
        A.4.3.  Router-LSAs
        A.4.4.  Network-LSAs
        A.4.5.  Inter-Area-Prefix-LSAs
        A.4.6.  Inter-Area-Router-LSAs
        A.4.7.  AS-external-LSAs
        A.4.8.  NSSA-LSAs
        A.4.9.  Link-LSAs
        A.4.10.  Intra-Area-Prefix-LSAs
Appendix B.  Architectural Constants
Appendix C.  Configurable Constants
    C.1.  Global parameters
    C.2.  Area parameters
    C.3.  Router interface parameters
    C.4.  Virtual link parameters
    C.5.  NBMA network parameters
    C.6.  Point-to-Multipoint network parameters
    C.7.  Host route parameters
Appendix D.  Change Log (To Be Removed Prior To Publication)
    D.1.  Changes from RFC 2740 to 00 Version
    D.2.  Changes from the 00 Version to the 01 Version
    D.3.  Changes from the 01 Version to the 02 Version
    D.4.  Changes from the 02 Version to the 03 Version
    D.5.  Changes from the 03 Version to the 04 Version
    D.6.  Changes from the 04 Version to the 05 Version
    D.7.  Changes from the 05 Version to the 06 Version
    D.8.  Changes from the 06 Version to the 07 Version
    D.9.  Changes from the 07 Version to the 08 Version
    D.10.  Changes from the 08 Version to the 09 Version
    D.11.  Changes from the 09 Version to the 10 Version
    D.12.  Changes from the 10 Version to the 11 Version
    D.13.  Changes from the 11 Version to the 12 Version
    D.14.  Changes from the 12 Version to the 13 Version
    D.15.  Changes from the 13 Version to the 14 Version
    D.16.  Changes from the 14 Version to the 15 Version
    D.17.  Changes from the 15 Version to the 16 Version
    D.18.  Changes from the 16 Version to the 17 Version
    D.19.  Changes from the 17 Version to the 18 Version
    D.20.  Changes from the 18 Version to the 19 Version
    D.21.  Changes from the 19 Version to the 20 Version
    D.22.  Changes from the 20 Version to the 21 Version
    D.23.  Changes from the 21 Version to the 22 Version
    D.24.  Changes from the 22 Version to the 23 Version
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

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, (Shortest Path First) 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. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF Version 3 (OSPFv3).

This document is organized as follows. Section 2 describes the differences between OSPF for IPv4 (OSPF Version 2) and OSPF for IPv6 (OSPF Version 3) in detail. Section 3 describes the difference between RFC 2740 and this document. Section 4 provides implementation details for the changes. Appendix A gives the OSPF for IPv6 packet and Link State Advertisement (LSA) formats. Appendix B lists the OSPF architectural constants. Appendix C describes configuration parameters.



 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

1.2.  Terminology

This document attempts to use terms from both the OSPF for IPv4 specification ([OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)) and the IPv6 protocol specifications ([IPV6] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.)). 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 (LSA format changes) 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).



 TOC 

2.  Differences from OSPF for IPv4

Most of the algorithms from OSPF for IPv4 [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) 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] (Moy, J., “OSPF Version 2,” April 1998.).



 TOC 

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] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.)). "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] (Moy, J., “OSPF Version 2,” April 1998.)) 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.



 TOC 

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:



 TOC 

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:



 TOC 

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.



 TOC 

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] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.). Link-local unicast addresses are assigned from the IPv6 address range 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] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.). 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 4.4.3.8 (Link-LSAs)). 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 4.4.3.4 (Inter-Area-Prefix-LSAs)), AS-external-LSAs (Section 4.4.3.6 (AS-external-LSAs)), NSSA-LSAs (Section 4.4.3.7 (NSSA-LSAs)), or intra-area-prefix-LSAs (Section 4.4.3.9 (Intra-Area-Prefix-LSAs)).



 TOC 

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] (Kent, S., “IP Authentication Header,” December 2005.)) and the IP Encapsulating Security Payload (see [IPESP] (Kent, S., “IP Encapsulation Security Payload (ESP),” December 2005.)) as described in [OSPFV3‑AUTH] (Gupta, M. and S. Melam, “Authentication/Confidentiality for OSPFv3,” June 2006.) to ensure integrity and authentication/confidentiality of routing exchanges.

Protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 Upper-Layer checksum (as described in section 8.1 of [IPV6] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.)), covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1 (The OSPF packet header)).



 TOC 

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:



 TOC 

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:



 TOC 

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 (LSA Type)).

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.



 TOC 

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 carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs.



 TOC 

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] (Moy, J., “OSPF Version 2,” April 1998.)), the lookup of neighbors (Section 10 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)) and the reception of Hello packets (Section 10.5 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)).

The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.



 TOC 

3.  Differences with RFC 2740

OSPFv3 implementations based on RFC 2740 will fully interoperate with implementations based on this specification. There are, however, some protocol additions and changes (all of which are backward compatible).



 TOC 

3.1.  Support for Multiple Interfaces on the same Link

This protocol feature was only partially specified in the RFC 2740. The level of specification was insufficient to implement the feature. Section 4.9 (Multiple interfaces to a single link) specifies the additions and clarifications necessary for implementation. They are fully compatible with RFC 2740.



 TOC 

3.2.  Deprecation of MOSPF for IPv6

This protocol feature was only partially specified in the RFC 2740. The level of specification was insufficient to implement the feature. There are no known implementations. MOSPF support and its attendant protocol fields have been deprecated from OSPFv3. Refer to Section 4.4.3.2 (Router-LSAs), Section 4.4.3.4 (Inter-Area-Prefix-LSAs), Section 4.4.3.6 (AS-external-LSAs), Section 4.4.3.7 (NSSA-LSAs), Appendix A.2 (The Options field), Appendix A.4.2.1 (LSA Type), Appendix A.4.3 (Router-LSAs), Appendix A.4.1.1 (Prefix Options), and Section 7.1 (MOSPF for OSPFv3 Deprecation IANA Considerations).



 TOC 

3.3.  NSSA Specification

This protocol feature was only partially specified in the RFC 2740. The level of specification was insufficient to implement the function. This document includes NSSA specification unique to OSPFv3. This specification coupled with [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.) provide sufficient specification for implementation. Refer to Section 4.8.5 (Calculating AS external and NSSA routes), Appendix A.4.3 (Router-LSAs), Appendix A.4.8 (NSSA-LSAs), and [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.).



 TOC 

3.4.  Stub Area Unknown LSA Flooding Restriction Deprecated

In RFC 2740 [OSPFV3] (Coltun, R., Ferguson, D., and J. Moy, “OSPF for IPv6,” December 1999.), flooding of unknown LSA was restricted within stub and NSSA areas. The text describing this restriction is included below.

     However, unlike in IPv4, IPv6 allows LSAs with unrecognized
     LS types to be labeled "Store and flood the LSA, as if type
     understood" (see the U-bit in Appendix A.4.2.1).  Uncontrolled
     introduction of such LSAs could cause a stub area's link-state
     database to grow larger than its component routers' capacities.

     To guard against this, the following rule regarding stub areas
     has been established: an LSA whose LS type is unrecognized can
     only be flooded into/throughout a stub area if both a) the LSA
     has area or link-local flooding scope and b) the LSA has U-bit
     set to 0.  See Section 3.5 for details.

This restriction has been deprecated. OSPFv3 routers will flood link and area scope LSAs whose LS type is unrecognized and whose U-bit is set to 1 throughout stub and NSSA areas. There are no backward compatibility issues other than OSPFv3 routers still supporting the restriction may not propagate newly defined LSA types.



 TOC 

3.5.  Link LSA Suppression

The LinkLSASuppression interface configuration parameter has been added. If LinkLSASuppression is configured for an interface and the interface type is not broadcast or NBMA, origination of the Link-LSA may be suppressed. The LinkLSASuppression interface configuration parameter is described in Appendix C.3 (Router interface parameters). Section 4.8.2 (The next hop calculation) and Section 4.4.3.8 (Link-LSAs) were updated to reflect the parameter's usage.



 TOC 

3.6.  LSA Options and Prefix Options Updates

The LSA options and Prefix Options fields have been updated to reflect recent protocols additions. Specifically, bits related to MOSPF have been deprecated, options field bits common with OSPFv2 have been reserved, and the DN-bit has been added to the prefix-options. Refer to Appendix A.2 (The Options field) and Appendix A.4.1.1 (Prefix Options).



 TOC 

3.7.  IPv6 Site-Local Addresses

All references to IPv6 site-local addresses have been removed.



 TOC 

4.  Implementation details

When going from IPv4 to IPv6, the basic OSPF mechanisms remain unchanged from those documented in [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). These mechanisms are briefly outlined in Section 4 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). 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] (Moy, J., “OSPF Version 2,” April 1998.) remains completely unchanged for IPv6:

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] (Moy, J., “OSPF Version 2,” April 1998.).

The following subsections provide a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.), with the following modifications:



 TOC 

4.1.1.  The Area Data structure

The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). 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.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.)) 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] (McCloghrie, K. and F. Kastenholz, “The interfaces Group MIB,” June 2000.)) 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 4.2 (Protocol Packet Processing)) 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.
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] (Kent, S., “IP Authentication Header,” December 2005.)) and the IP Encapsulating Security Payload (see [IPESP] (Kent, S., “IP Encapsulation Security Payload (ESP),” December 2005.)) as described in [OSPFV3‑AUTH] (Gupta, M. and S. Melam, “Authentication/Confidentiality for OSPFv3,” June 2006.) 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] (Moy, J., “OSPF Version 2,” April 1998.) respectively. The Designated Router and Backup Designated Router election algorithm also remains unchanged from the IPv4 election in Section 9.4 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.).



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.) 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.
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] (Moy, J., “OSPF Version 2,” April 1998.) respectively. The decision as to which adjacencies to form also remains unchanged from the IPv4 logic documented in Section 10.4 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.).



 TOC 

4.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.



 TOC 

4.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 (The OSPF packet header)) 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).
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 Upper-Layer checksum (as described in section 8.1 of [IPV6] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.)) covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1 (The OSPF packet header)).

Selection of OSPF routing protocol packets' IPv6 source and destination addresses is performed identically to the IPv4 logic in Section 8.1 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). 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] (Moy, J., “OSPF Version 2,” April 1998.) 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.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.)):

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] (Moy, J., “OSPF Version 2,” April 1998.).



 TOC 

4.2.1.2.  Sending Database Description Packets

The sending of Database Description packets differs from Section 10.8 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) in the following ways:



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.). 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:

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:

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 4.2.2.1 (Receiving Hello Packets). 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] (Moy, J., “OSPF Version 2,” April 1998.) respectively with the exceptions noted below.

The receiving of Hello packets is documented in Section 4.2.2.1 (Receiving Hello Packets) and the receiving of Link State Update packets is documented in Section 4.5.1 (Receiving Link State Update packets).



 TOC 

4.2.2.1.  Receiving Hello Packets

The receive processing of Hello packets differs from Section 10.5 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) in the following ways:



 TOC 

4.3.  The Routing table Structure

The routing table used by OSPF for IPv4 is defined in Section 11 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). 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 4.8 (Routing table calculation)).

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:

The fields in the IPv4 OSPF routing table (see Section 11 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)) 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 (Intra-Area-Prefix-LSAs)).



 TOC 

4.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.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.), and is not encoded within OSPF for IPv6's LSAs.

These changes will be described in detail in the following subsections.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.) 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 (The Options field)). 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 (LSA Type) for the current coding of the LS type field.
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.


 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.)).

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 4.1 (Protocol data structures)) 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 4.1.1 (The Area Data structure)) 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 4.1.2 (The Interface Data structure)); 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.



 TOC 

4.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 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] (Moy, J., “OSPF Version 2,” April 1998.). The following events and/or actions are added for IPv6:

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] (Moy, J., “OSPF Version 2,” April 1998.) 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 2001:0db8:c001::/48. The OSPF interface IDs and the link-local addresses for the router interfaces in Figure 1 are given in Table 2.


       ..........................................
       .                                  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        2001:0db8:c001:0200::/56
              N2        2001:0db8:c001:0300::/56
              N3        2001:0db8:c001:0100::/56
              N4        2001:0db8: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

 Figure 1 



 TOC 

4.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] (Moy, J., “Extending OSPF to Support Demand Circuits,” April 1995.)). 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.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.).

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 (Router-LSAs)). 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 4.9 (Multiple interfaces to a single link)). 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.

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 4.7 (Virtual links)).
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.


     ; 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.0.2.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.0.2.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.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.), with the following exceptions:

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.0.2.4 ;RT4's Router ID
     Options = (V6-bit|E-bit|R-bit)
            Attached Router = 192.0.2.4    ;Router ID
            Attached Router = 192.0.2.1    ;Router ID
            Attached Router = 192.0.2.2    ;Router ID
            Attached Router = 192.0.2.3    ;Router ID

 Network-LSA for Network N3 



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.), with the following exceptions:

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 2001:0db8: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.0.2.4       ;RT4's ID
        Metric = 4                  ;maximum to components
        PrefixLength = 48
        PrefixOptions = 0
        Address Prefix = 2001:0db8:c001 ;padded to 64-bits

 Inter-area-prefix-LSA for Area 1 addresses originated by Router RT4 into the backbone 



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.), with the following exceptions:

As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). 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.0.2.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 



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.), with the following exceptions:

As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). 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 2001:0db8: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 = 2001:0db8:0a00 ;padded to 64-bits
     External Route Tag = as per BGP/OSPF interaction

 AS-external-LSA for Network N12, originated by Router RT7 



 TOC 

4.4.3.7.  NSSA-LSAs

The LS type of an NSSA-LSA is set to the value 0x2007. 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] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.), with the following exceptions:

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.



 TOC 

4.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 broadcast or NBMA link.

A link-LSA for a given Link L is built in the following fashion:

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 4.8.2 (The next hop calculation)). Refer to Appendix C.3 (Router interface parameters) 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 2001:0db8: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.


     ; 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.0.2.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 = 2001:0db8:c001:0100 ;pad to 64-bits

 RT3's link-LSA for N3 



 TOC 

4.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:

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:

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.0.2.4 ;RT4's Router ID
     # prefixes = 1
     Referenced LS Type = 0x2002 ;network-LSA reference
     Referenced Link State ID = 1
     Referenced Advertising Router = 192.0.2.4
     PrefixLength = 56           ;N3's prefix
     PrefixOptions = 0
     Metric = 0
     Address Prefix = 2001:0db8: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.0.2.3 ;RT3's Router ID
     # prefixes = 1
     Referenced LS Type = 0x2001 ;router-LSA reference
     Referenced Link State ID = 0
     Referenced Advertising Router = 192.0.2.3
     PrefixLength = 56           ;N4's prefix
     PrefixOptions = 0
     Metric = 2                  ;N4 interface cost
     Address Prefix = 2001:0db8:c001:0400 ;pad

 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.



 TOC 

4.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 4.8 (Routing table calculation). For example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE] (Coltun, R., “The OSPF Opaque LSA Option,” July 1998.). 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).



 TOC 

4.5.  Flooding

Most of the flooding algorithm remains unchanged from the IPv4 flooding mechanisms described in Section 13 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). In particular, the protocol processes for determining which LSA instance is newer (Section 13.1 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)), responding to updates of self-originated LSAs (Section 13.4 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)), sending Link State Acknowledgment packets (Section 13.5 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)), retransmitting LSAs (Section 13.6 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)), and receiving Link State Acknowledgment packets (Section 13.7 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)) 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 (LSA Type)) has caused some changes in the OSPF flooding algorithm: the reception of Link State Updates (Section 13 in [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)) and the sending of Link State Updates (Section 13.3 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)) 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] (Moy, J., “OSPF Version 2,” April 1998.)) causes different events in IPv6, due to the reorganization of LSA types and the IPv6 LSA contents. These changes are described in detail below.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.). 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] (Moy, J., “OSPF Version 2,” April 1998.) are also somewhat different for IPv6, as described in Sections 3.5.2 and 3.5.3 below.



 TOC 

4.5.2.  Sending Link State Update packets

The sending of Link State Update packets is described in Section 13.3 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). 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] (Moy, J., “OSPF Version 2,” April 1998.)). However, the list of eligible interfaces on which to flood the LSA is different. For IPv6, the eligible interfaces are selected based on the following factors:

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 13.3 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)). 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.



 TOC 

4.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 4.1 (Protocol data structures)) 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 4.1.1 (The Area Data structure)) 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] (Moy, J., “OSPF Version 2,” April 1998.). 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 4.8 (Routing table calculation)).
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] (Moy, J., “OSPF Version 2,” April 1998.)). 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] (Moy, J., “OSPF Version 2,” April 1998.) and Section 2.0 in [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.)).

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.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.). For IPv6, self-originated LSAs are those LSAs whose Advertising Router is equal to the router's own Router ID.



 TOC 

4.7.  Virtual links

OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). Virtual links are the same in IPv6, with the following exceptions:



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.). High level differences between the IPv6 and IPv4 calculations include:

For each area, the shortest-path tree calculation creates routing table entries for the area's routers and transit links (see Section 4.8.1 (Calculating the shortest path tree for an area)). These entries are then used when processing intra-area-prefix-LSAs, inter-area-prefix-LSAs, and inter-area-router-LSAs, as described in Section 4.8.3 (Calculating the inter-area routes).

Events generated as a result of routing table changes (Section 16.7 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)) and the equal-cost multipath logic (Section 16.8 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)) are identical for both IPv4 and IPv6.



 TOC 

4.8.1.  Calculating the shortest path tree for an area

The IPv4 shortest path calculation is contained in Section 16.1 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). 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 routing table entries within the area (see Section 4.3 (The Routing table Structure)).

Section 16.1 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) 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] (Moy, J., “OSPF Version 2,” April 1998.)):

The next stage of the shortest path calculation proceeds similarly to the two steps of the second stage of Section 16.1 in [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). 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.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.)). 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 (Link-LSAs)) 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] (Moy, J., “OSPF Version 2,” April 1998.)) 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.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.), with the following modifications:

When a single inter-area-prefix-LSA or inter-area-router-LSA has changed, the incremental calculations outlined in Section 16.5 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) can be performed instead of recalculating the entire routing table.



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.), modified in the same way as the IPv6 inter-area route calculation in Section 4.8.3 (Calculating the inter-area routes).



 TOC 

4.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] (Moy, J., “OSPF Version 2,” April 1998.) and Section 2.5 of [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.), with the following exceptions:

When a single AS-external-LSA or NSSA-LSA has changed, the incremental calculations outlined in Section 16.6 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) can be performed instead of recalculating the entire routing table.



 TOC 

4.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:



 TOC 

4.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:



     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 



 TOC 

5.  Security Considerations

When running over IPv6, OSPFv3 relies on the IP Authentication Header (see [IPAUTH] (Kent, S., “IP Authentication Header,” December 2005.)) and the IP Encapsulating Security Payload (see [IPESP] (Kent, S., “IP Encapsulation Security Payload (ESP),” December 2005.)) to ensure integrity and authentication/confidentiality of protocol packets. This is described in [OSPFV3‑AUTH] (Gupta, M. and S. Melam, “Authentication/Confidentiality for OSPFv3,” June 2006.).

Most OSPFv3 implementations will be running on systems that support multiple protocols with their own independent security assumptions and domains. When IPsec is used to protect OSPFv3 packets, it is important for the implementation to check the IPsec Security Association (SA) and local SA database to assure the OSPF packet originated from a source that is trusted for OSPFv3. This required to eliminate the possibility that the packet was authenticated using an SA defined for another protocol running on the same system.

The mechanisms in [OSPFV3‑AUTH] (Gupta, M. and S. Melam, “Authentication/Confidentiality for OSPFv3,” June 2006.) do not provide protection against compromised, malfunctioning, or misconfigured routers. Such routers can, either accidentally or deliberately, cause malfunctions affecting the whole routing domain. The reader is encouraged to consult [GENERIC‑THREATS] (Barbir, A., Murphy, S., and Y. Yang, “Generic Threats to Routing Protocols,” October 2006.) for a more comprehensive description of threats to routing protocols.



 TOC 

6.  Manageability Considerations

The Management Information Base (MIB) for OSPFv3 is defined in [OSPFV3‑MIB] (Joyal, D. and V. Manral, “Management Information Base for OSPFv3,” .).



 TOC 

7.  IANA Considerations

Most OSPF for IPv6 IANA considerations are documented in [OSPF‑IANA] (Kompella, K. and B. Fenner, “IANA Considerations for OSPF,” July 2007.). IANA is requested to change the reference for RFC2740 to this document. (to be removed before publication)

Additionally, this document introduces the following IANA requirements that were not present in [OSPFV3] (Coltun, R., Ferguson, D., and J. Moy, “OSPF for IPv6,” December 1999.):



 TOC 

7.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] (Kompella, K. and B. Fenner, “IANA Considerations for OSPF,” July 2007.) for information on the respective registries.

The W-bit in the OSPFv3 router properties has also been deprecated. This requires a new registry for OSPFv3 router properties since it will diverge from the OSPFv2 router properties.


   Registry Name: OSPFv3 Router Properties Registry
   Reference: RFC-ietf-ospf-ospfv3-update (This Document)
   Registration Procedures: Standards Action

   Registry:
   Value   Description    Reference
   ------  -------------  ---------
   0x01    B-bit          RFC-ietf-ospf-ospfv3-update (This Document)
   0x02    E-bit          RFC-ietf-ospf-ospfv3-update (This Document)
   0x04    V-bit          RFC-ietf-ospf-ospfv3-update (This Document)
   0x08    Deprecated     RFC-ietf-ospf-ospfv3-update (This Document)
   0x10    Nt-bit         RFC-ietf-ospf-ospfv3-update (This Document)

 OSPFv3 Router Properties Registry 



 TOC 

8.  Acknowledgments

The RFC text was produced using Marshall Rose's xml2rfc tool.

The following individuals contributed comments which that incorporated into this document:



 TOC 

9.  References



 TOC 

9.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,” RFC 2863, June 2000.
[IP6ADDR] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” RFC 4291, February 2006.
[IPAUTH] Kent, S., “IP Authentication Header,” RFC 4302, December 2005.
[IPESP] Kent, S., “IP Encapsulation Security Payload (ESP),” RFC 4303, December 2005.
[IPV4] Postal, J., “Internet Protocol,” RFC 791, September 1981.
[IPV6] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998.
[NSSA] Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” RFC 3101, January 2003.
[OSPF-IANA] Kompella, K. and B. Fenner, “IANA Considerations for OSPF,” RFC 4940, July 2007.
[OSPFV2] Moy, J., “OSPF Version 2,” RFC 2328, April 1998.
[OSPFV3-AUTH] Gupta, M. and S. Melam, “Authentication/Confidentiality for OSPFv3,” RFC 4552, June 2006.
[RFC-KEYWORDS] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, March 1997.


 TOC 

9.2. Informative References

[GENERIC-THREATS] Barbir, A., Murphy, S., and Y. Yang, “Generic Threats to Routing Protocols,” RFC 4593, October 2006.
[MOSPF] Moy, J., “Multicast Extensions to OSPF,” RFC 1584, March 1994.
[MTUDISC] Mogul, J. and S. Deering, “Path MTU Discovery,” RFC 1191, November 1990.
[OPAQUE] Coltun, R., “The OSPF Opaque LSA Option,” RFC 2370, July 1998.
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, “OSPF for IPv6,” RFC 2740, December 1999.
[OSPFV3-MIB] Joyal, D. and V. Manral, “Management Information Base for OSPFv3,” draft-ietf-ospf-ospfv3-mib-12.txt (work in progress).
[SERV-CLASS] Baker, F., Chan, K., and J. Babiarz, “Configuration Guidelines for DiffServ Service Classes,” RFC 4594, August 2006.


 TOC 

Appendix A.  OSPF data formats

This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IPv6 network layer. Before any data formats are described, the details of the OSPF encapsulation are explained.

Next the OSPF Options field is described. This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets, and OSPF LSAs.

OSPF packet formats are detailed in Section A.3.

A description of OSPF LSAs appears in Section A.4. This section describes how IPv6 address prefixes are represented within LSAs, details the standard LSA header, and then provides formats for each of the specific LSA types.



 TOC 

A.1.  Encapsulation of OSPF packets

OSPF runs directly over the IPv6's network layer. OSPF packets are therefore encapsulated solely by IPv6 and local data-link headers.

OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes. The OSPF packet types that are likely to be large (Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into multiple protocol packets without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the size of OSPF packets sent over virtual links to 1280 bytes unless Path MTU Discovery is being performed [MTUDISC] (Mogul, J. and S. Deering, “Path MTU Discovery,” November 1990.).

The other important features of OSPF's IPv6 encapsulation are:



 TOC 

A.2.  The Options field

The 24-bit OSPF Options field is present in OSPF Hello packets, Database Description packets, and certain LSAs (router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs). The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism routers of differing capabilities can be mixed within an OSPF routing domain.

An option mismatch between routers can cause a variety of behaviors, depending on the particular option. Some option mismatches prevent neighbor relationships from forming (e.g., the E-bit below); these mismatches are discovered through the sending and receiving of Hello packets. Some option mismatches prevent particular LSA types from being flooded across adjacencies these are discovered through the sending and receiving of Database Description packets. Some option mismatches prevent routers from being included in one or more of the various routing calculations because of their reduced functionality; these mismatches are discovered by examining LSAs.

Seven bits of the OSPF Options field have been assigned. Each bit is described briefly below. Routers should reset (i.e., clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating LSAs. Conversely, routers encountering unrecognized Option bits in received Hello packets, Database Description packets, or LSAs should ignore the unrecognized bits and process the packet or LSA normally.



                            1                    2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9 0 1  2  3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
       | | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+

                        The Options field

 The Options field 



V6-bit
If this bit is clear, the router/link should be excluded from IPv6 routing calculations. See Section 4.8 (Routing table calculation) for details.
E-bit
This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.).
x-Bit
This bit was previously used by MOSPF (see [MOSPF] (Moy, J., “Multicast Extensions to OSPF,” March 1994.)) that has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
N-bit
This bit indicates whether or not the router is attached to an NSSA as specified in [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.).
R-bit
This bit (the `Router' bit) indicates whether the originator is an active router. If the router bit is clear, then routes which transit the advertising node cannot be computed. Clearing the router bit would be appropriate for a multi-homed host that wants to participate in routing, but does not want to forward non-locally addressed packets.
DC-bit
This bit describes the router's handling of demand circuits, as specified in [DEMAND] (Moy, J., “Extending OSPF to Support Demand Circuits,” April 1995.).
*-bit
These bits are reserved for migration of OSPFv2 protocol extensions.


 TOC 

A.3.  OSPF Packet Formats

There are five distinct OSPF packet types. All OSPF packet types begin with a standard 16 byte header. This header is described first. Each packet type is then described in a succeeding section. In these sections each packet's format is displayed and the packet's component fields are defined.

All OSPF packet types (other than the OSPF Hello packets) deal with lists of LSAs. For example, Link State Update packets implement the flooding of LSAs throughout the OSPF routing domain. The format of LSAs is described in Section A.4.

The receive processing of OSPF packets is detailed in Section 4.2.2 (Receiving Protocol Packets). The sending of OSPF packets is explained in Section 4.2.1 (Sending protocol packets).



 TOC 

A.3.1.  The OSPF packet header

Every OSPF packet starts with a standard 16 byte header. Together with the encapsulating IPv6 headers, the OSPF header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 4.2.2 (Receiving Protocol Packets).


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version #   |     Type      |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The OSPF Packet Header 



Version #
The OSPF version number. This specification documents version 3 of the OSPF protocol.
Type
The OSPF packet types are as follows. See Appendix A.3.2 (The Hello Packet) through Appendix A.3.6 (The Link State Acknowledgment Packet) for details.
         Type   Description
         ---------------------------------
         1      Hello
         2      Database Description
         3      Link State Request
         4      Link State Update
         5      Link State Acknowledgment
Packet length
The length of the OSPF protocol packet in bytes. This length includes the standard OSPF header.
Router ID
The Router ID of the packet's source.
Area ID
A 32 bit number identifying the area that this packet belongs to. All OSPF packets are associated with a single area. Most travel a single hop only. Packets traversing a virtual link are labeled with the backbone Area ID of 0.
Checksum
OSPF uses the standard checksum calculation for IPv6 applications: The 16-bit one's complement of the one's complement sum of the entire contents of the packet, starting with the OSPF packet header, and prepending a "pseudo-header" of IPv6 header fields, as specified in section 8.1 of [IPV6] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.). The "Upper-Layer Packet Length" in the pseudo-header is set to value of the OSPF packet header's length field. The Next Header value used in the pseudo-header is 89. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. Before computing the checksum, the checksum field in the OSPF packet header is set to 0.
Instance ID
Enables multiple instances of OSPF to be run over a single link. Each protocol instance would be assigned a separate Instance ID; the Instance ID has local link significance only. Received packets whose Instance ID is not equal to the receiving interface's Instance ID are discarded.
0
These fields are reserved. They SHOULD be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets.


 TOC 

A.3.2.  The Hello Packet

Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello packets are multicast on those links having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.

All routers connected to a common link must agree on certain parameters (HelloInterval and RouterDeadInterval). These parameters are included in Hello packets allowing differences to inhibit the forming of neighbor relationships. The Hello packet also contains fields used in Designated Router election (Designated Router ID and Backup Designated Router ID), and fields used to detect bidirectional communication (the Router IDs of all neighbors whose Hellos have been recently received).


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       1       |         Packet Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             | Instance ID   |     0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Interface ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rtr Priority  |             Options                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        HelloInterval          |       RouterDeadInterval      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Designated Router ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Backup Designated Router ID                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Neighbor ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ...                                    |

 The OSPF Hello Packet 



Interface ID
32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some implementations it may be possible to use the MIB-II IfIndex ([INTFMIB] (McCloghrie, K. and F. Kastenholz, “The interfaces Group MIB,” June 2000.)).
Rtr Priority
This router's Router Priority. Used in (Backup) Designated Router election. If set to 0, the router will be ineligible to become (Backup) Designated Router.
Options
The optional capabilities supported by the router, as documented in Section A.2.
HelloInterval
The number of seconds between this router's Hello packets.
RouterDeadInterval
The number of seconds before declaring a silent router down.
Designated Router ID
The sending router's view of the identity of the Designated Router for this network. The Designated Router is identified by its Router ID. It is set to 0.0.0.0 if there is no Designated Router.
Backup Designated Router ID
The sending router's view of the identity of the Backup Designated Router for this network. The Backup Designated Router is identified by its IP Router ID. It is set to 0.0.0.0 if there is no Backup Designated Router.
Neighbor ID
The Router IDs of each router on the network with neighbor state 1-Way or greater.


 TOC 

A.3.3.  The Database Description Packet

Database Description packets are OSPF packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose a poll-response procedure is used. One of the routers is designated to be the master and the other is the slave. The master sends Database Description packets (polls) that are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.




    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
   |      3        |       2       |        Packet Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
   |                           Router ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
   |                             Area ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
   |           Checksum            |  Instance ID  |      0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
   |       0       |               Options                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
   |        Interface MTU          |      0        |0|0|0|0|0|I|M|MS|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
   |                    DD sequence number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
   |                                                                |
   +-                                                              -+
   |                                                                |
   +-                     An LSA Header                            -+
   |                                                                |
   +-                                                              -+
   |                                                                |
   +-                                                              -+
   |                                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
   |                       ...                                      |
 The OSPF Database Description Packet 

The format of the Database Description packet is very similar to both the Link State Request packet and the Link State Acknowledgment packet. The main part of all three is a list of items, each item describing a piece of the link-state database. The sending of Database Description packets is documented in Section 10.8 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). The reception of Database Description packets is documented in Section 10.6 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.).

Options
The optional capabilities supported by the router, as documented in Section A.2.
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent out the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC] (Mogul, J. and S. Deering, “Path MTU Discovery,” November 1990.). Interface MTU should be set to 0 in Database Description packets sent over virtual links.
I-bit
The Init bit. When set to 1, this packet is the first in the sequence of Database Description packets.
M-bit
The More bit. When set to 1, it indicates that more Database Description packets are to follow.
MS-bit
The Master/Slave bit. When set to 1, it indicates that the router is the master during the Database Exchange process. Otherwise, the router is the slave.
DD sequence number
Used to sequence the collection of Database Description packets. The initial value (indicated by the Init bit being set) should be unique. The DD sequence number then increments until the complete database description for both the master and slave routers have been exchanged.

The rest of the packet consists of a (possibly partial) list of the link-state database's pieces. Each LSA in the database is described by its LSA header. The LSA header is documented in Appendix A.4.2 (The LSA header). It contains all the information required to uniquely identify both the LSA and the LSA's current instance.



 TOC 

A.3.4.  The Link State Request Packet

Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used.

A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting. Each instance is defined by its LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request packet itself. The router may receive even more recent LSA instances in response.

The sending of Link State Request packets is documented in Section 10.9 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). The reception of Link State Request packets is documented in Section 10.7 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.).



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       3       |        Packet Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Area ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              0                |        LS Type                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Link State ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Advertising Router                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                 ...                           |

 The OSPF List State Request Packet 

Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA without specifying its instance. Link State Request packets are understood to be requests for the most recent instance of the specified LSAs.



 TOC 

A.3.5.  The Link State Update Packet

Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet.

Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always carried by unicast Link State Update packets. For more information on the reliable flooding of LSAs, consult Section 4.5 (Flooding).



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       4       |         Packet Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           # LSAs                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                            +-+
   |                            LSAs                               |
   +-                                                            +-+
   |                             ...                               |

 The OSPF List State Request Packet 



# LSAs
The number of LSAs included in this update.

The body of the Link State Update packet consists of a list of LSAs. Each LSA begins with a common 20 byte header, described in Appendix A.4.2 (The LSA header). Detailed formats of the different types of LSAs are described Appendix A.4 (LSA formats).



 TOC 

A.3.6.  The Link State Acknowledgment Packet

Link State Acknowledgment packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly or implicitly acknowledged. Explicit acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. The sending of Link State Acknowledgment packets is documented in Section 13.5 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). The reception of Link State Acknowledgment packets is documented in Section 13.7 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.).

Multiple LSAs MAY be acknowledged in a single Link State Acknowledgment packet. Depending on the state of the sending interface and the sender of the corresponding Link State Update packet, a Link State Acknowledgment packet is sent to the multicast address AllSPFRouters, the multicast address AllDRouters, or to a neighbor's unicast address (see Section 13.5 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) for details).

The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of LSA headers.



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       5       |        Packet Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                        An LSA Header                        -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ...                              |

 The OSPF List State Acknowledgment Packet 

Each acknowledged LSA is described by its LSA header. The LSA header is documented in Appendix A.4.2 (The LSA header). It contains all the information required to uniquely identify both the LSA and the LSA's current instance.



 TOC 

A.4.  LSA formats

This document defines eight distinct types of LSAs. Each LSA begins with a standard 20 byte LSA header. This header is explained in Appendix A.4.2 (The LSA header). Succeeding sections describe each LSA type individually.

Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. A network-LSA is advertised for each link by its Designated Router. A router's link-local addresses are advertised to its neighbors in link-LSAs. IPv6 prefixes are advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs, AS-external-LSAs, and NSSA-LSAs. Location of specific routers can be advertised across area boundaries in inter-area-router-LSAs. All LSAs are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers common to a flooding scope have the same collection of LSAs associated with that flooding scope. (See Section 4.5 (Flooding) for more information concerning the flooding algorithm). This collection of LSAs is called the link-state database.

From the link-state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)). For the details of the routing table build process, see Section 4.8 (Routing table calculation).



 TOC 

A.4.1.  IPv6 Prefix Representation

IPv6 addresses are bit strings of length 128. IPv6 routing protocols, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive).

Within OSPF, IPv6 address prefixes are always represented by a combination of three fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities associated with the prefix (see Appendix A.4.2 (The LSA header)). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padding with zero bits as necessary. This encoding consumes ((PrefixLength + 31) / 32) 32-bit words.

The default route is represented by a prefix of length 0.

Examples of IPv6 Prefix representation in OSPF can be found in Appendix A.4.5 (Inter-Area-Prefix-LSAs), Appendix A.4.7 (AS-external-LSAs), Appendix A.4.8 (NSSA-LSAs), Appendix A.4.9 (Link-LSAs), and Appendix A.4.10 (Intra-Area-Prefix-LSAs).



 TOC 

A.4.1.1.  Prefix Options

Each prefix is advertised along with an 8-bit field of capabilities. These serve as input to the various routing calculations. For example, they can indicate that prefixes are to be ignored in some cases or are to be marked as not readvertisable in others.


                  0  1  2  3  4  5  6  7
                 +--+--+--+--+--+-+--+--+
                 |  |  |  |DN| P|x|LA|NU|
                 +--+--+--+--+--+-+--+--+


 The Prefix Options field 



NU-bit
The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations. If not set, it should be included.
LA-bit
The "local address" capability bit. If set, the prefix is actually an IPv6 interface address of the advertising router. Advertisement of local interface addresses is described in Section 4.4.3.9 (Intra-Area-Prefix-LSAs). An implementation MAY also set the LA-bit for prefixes advertised with a host PrefixLength (128).
x-bit
This bit was previously defined as a "multicast" capability bit. However, the use was never adequately specified and has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
P-bit
The "propagate" bit. Set on NSSA area prefixes that should be readvertised by the translating NSSA area border [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.).
DN-bit
This bit controls an inter-area-prefix-LSAs or AS-external-LSAs re-advertisement in a VPN environment as specified in [DN‑BIT] (Rosen, E., Peter, P., and P. Pillay-Esnault, “Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs,” April 2005.).


 TOC 

A.4.2.  The LSA header

All LSAs begin with a common 20 byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number, and LS checksum fields that are also contained in the LSA header.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS Age              |           LS Type             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS Checksum            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The LSA Header 



LS Age
The time in seconds since the LSA was originated.
LS Type
The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. See Appendix A.4.2.1 (LSA Type) for a detailed description of LS type.
LS State ID
The originating router's identifier for the LSA. The combination of the LS State ID, LS type, and Advertising Router uniquely identify the LSA in the link-state database.
Advertising Router
The Router ID of the router that originated the LSA. For example, in network-LSAs this field is equal to the Router ID of the network's Designated Router.
LS sequence number
Successive instances of an LSA are given successive LS sequence numbers. The sequence number can be used to detect old or duplicate LSA instances. See Section 12.1.6 in [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) for more details.
LS checksum
The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the LS age field. See Section 12.1.7 in [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) for more details.
length
The length in bytes of the LSA. This includes the 20 byte LSA header.


 TOC 

A.4.2.1.  LSA Type

The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. The format of the LS type is as follows:



           0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         |U |S2|S1|           LSA Function Code          |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

 LSA Type 

The U bit indicates how the LSA should be handled by a router which does not recognize the LSA's function code. Its values are:



     U-bit   LSA Handling
     -------------------------------------------------------------
     0       Treat the LSA as if it had link-local flooding scope
     1       Store and flood the LSA as if the type is understood

 U Bit 

The S1 and S2 bits indicate the flooding scope of the LSA. The values are:



  S2  S1   Flooding Scope
  -------------------------------------------------------------
  0  0    Link-Local Scoping - Flooded only on originating link
  0  1    Area Scoping - Flooded only in originating area
  1  0    AS Scoping - Flooded throughout AS
  1  1    Reserved

 Flooding Scope 

The LSA function codes are defined as follows. The origination and processing of these LSA function codes are defined elsewhere in this document, except for the NSSA-LSA (see [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.)) and 0x2006 which was previously used by MOSPF (see [MOSPF] (Moy, J., “Multicast Extensions to OSPF,” March 1994.)). MOSPF has been deprecated for OSPFv3. As shown below, each LSA function code also implies a specific setting for the U, S1, and S2 bits.



         LSA function code   LS Type   Description
         ----------------------------------------------------
         1                   0x2001    Router-LSA
         2                   0x2002    Network-LSA
         3                   0x2003    Inter-Area-Prefix-LSA
         4                   0x2004    Inter-Area-Router-LSA
         5                   0x4005    AS-external-LSA
         6                   0x2006    Deprecated (May be reassigned)
         7                   0x2007    NSSA-LSA
         8                   0x0008    Link-LSA
         9                   0x2009    Intra-Area-Prefix-LSA

 LSA function code 



 TOC 

A.4.3.  Router-LSAs

Router-LSAs have LS type equal to 0x2001. Each router in an area originates one or more router-LSAs. The complete collection of router-LSAs originated by the router describe the state and cost of the router's interfaces to the area. For details concerning the construction of router-LSAs, see Section 4.4.3.2 (Router-LSAs)). Router-LSAs are only flooded throughout a single area.




    0                    1                   2                   3
    0 1 2 3  4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS Age               |0|0|1|         1               |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                            |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                          |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS Sequence Number                          |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS Checksum             |            Length             |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  0  |Nt|x|V|E|B|            Options                            |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type       |       0       |          Metric               |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface ID                              |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Neighbor Interface ID                        |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Router ID                          |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                                |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type       |       0       |          Metric               |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface ID                              |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Neighbor Interface ID                        |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Router ID                          |
   +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                                |
 Router LSA format 

A single router may originate one or more Router LSAs, distinguished by their Link-State IDs (which are chosen arbitrarily by the originating router). The Options field and V, E and B bits should be the same in all Router LSAs from a single originator. However, in the case of a mismatch, the values in the LSA with the lowest Link State ID take precedence. When more than one Router LSA is received from a single router, the links are processed as if concatenated into a single LSA.

Bit V
When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as transit area (V is for virtual link endpoint).
Bit E
When set, the router is an AS boundary router (E is for external).
Bit B
When set, the router is an area border router (B is for border).
Bit x
This bit was previously used by MOSPF (see [MOSPF] (Moy, J., “Multicast Extensions to OSPF,” March 1994.)) that has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
Bit Nt
When set, the router is an NSSA border router that is unconditionally translating NSSA LSAs into AS-External LSAs (Nt stands for NSSA translation). Note that such routers have their NSSATranslatorRole area configuration parameter set to Always. [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.)
Options
The optional capabilities supported by the router, as documented in Appendix A.2 (The Options field)).

The following fields are used to describe each router interface. The Type field indicates the kind of interface being described. It may be an interface to a transit network, a point-to-point connection to another router, or a virtual link. The values of all the other fields describing a router interface depend on the interface's Type field.

Type
The kind of interface being described. One of the following:

          Type   Description
          ---------------------------------------------------
          1      Point-to-point connection to another router
          2      Connection to a transit network
          3      Reserved
          4      Virtual link
 Router Link Types 

Metric
The cost of using this router interface for outbound traffic.
Interface ID
The Interface ID assigned to the interface being described. See Section 4.1.2 (The Interface Data structure) and Appendix C.3 (Router interface parameters).
Neighbor Interface ID
The Interface ID the neighbor router has associated with the link, as advertised in the neighbor's Hello packets. For transit (type 2) links, the link's Designated Router is the neighbor described. For other link types, the sole adjacent neighbor is described.
Neighbor Router ID
The Router ID the of the neighbor router. For transit (type 2) links, the link's Designated Router is the neighbor described. For other link types, the sole adjacent neighbor is described.

For transit (Type 2) links, the combination of Neighbor Interface ID and Neighbor Router ID allows the network-LSA for the attached link to be found in the link-state database.



 TOC 

A.4.4.  Network-LSAs

Network-LSAs have LS type equal to 0x2002. A network-LSA is originated for each broadcast and NBMA link in the area which includes two or more adjacent routers. The network-LSA is originated by the link's Designated Router. The LSA describes all routers attached to the link including the Designated Router itself. The LSA's Link State ID field is set to the Interface ID that the Designated Router has been advertising in Hello packets on the link.

The distance from the network to all attached routers is zero. This is why the metric fields need not be specified in the network-LSA. For details concerning the construction of network-LSAs, see Section 4.4.3.3 (Network-LSAs)).


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS Age              |0|0|1|          2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS Checksum            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |              Options                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Attached Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |

 Network LSA format 



Attached Router
The Router IDs of each of the routers attached to the link. Actually, only those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the LSA header's length field.


 TOC 

A.4.5.  Inter-Area-Prefix-LSAs

Inter-area-prefix-LSAs have LS type equal to 0x2003. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see Section 12.4.3 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)). Originated by area border routers, they describe routes to IPv6 address prefixes that belong to other areas. A separate inter-area-prefix-LSA is originated for each IPv6 address prefix. For details concerning the construction of inter-area-prefix-LSAs, see Section 4.4.3.4 (Inter-Area-Prefix-LSAs)).

For stub areas, inter-area-prefix-LSAs can also be used to describe a (per-area) default route. Default summary routes are used in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the inter-area-prefix-LSA's PrefixLength is set to 0.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS Age              |0|0|1|          3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS Checksum            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |                  Metric                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PrefixLength  | PrefixOptions |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Inter-Area-Prefix-LSA format 



Metric
The cost of this route. Expressed in the same units as the interface costs in router-LSAs. When the inter-area-prefix-LSA is describing a route to a range of addresses (see Appendix C.2 (Area parameters)), the cost is set to the maximum cost to any reachable component of the address range.
PrefixLength, PrefixOptions, and Address Prefix
Representation of the IPv6 address prefix, as described in Appendix A.4.1 (IPv6 Prefix Representation)


 TOC 

A.4.6.  Inter-Area-Router-LSAs

Inter-area-router-LSAs have LS type equal to 0x2004. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see Section 12.4.3 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)). Originated by area border routers, they describe routes to AS boundary routers in other areas. To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 in [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). Each LSA describes a route to a single router. For details concerning the construction of inter-area-router-LSAs, see Section 4.4.3.5 (Inter-Area-Router-LSAs).


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS Age              |0|0|1|        4                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS Checksum            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |                 Options                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |                 Metric                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Router ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Inter-Area-Router-LSA format 



Options
The optional capabilities supported by the router, as documented in Appendix A.2 (The Options field).
Metric
The cost of this route. Expressed in the same units as the interface costs in router-LSAs.
Destination Router ID
The Router ID of the router being described by the LSA.


 TOC 

A.4.7.  AS-external-LSAs

AS-external-LSAs have LS type equal to 0x4005. These LSAs are originated by AS boundary routers and describe destinations external to the AS. Each LSA describes a route to a single IPv6 address prefix. For details concerning the construction of AS-external-LSAs, see Section 4.4.3.6 (AS-external-LSAs).

AS-external-LSAs can be used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the AS-external-LSA's PrefixLength is set to 0.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS Age              |0|1|0|          5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS Checksum            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         |E|F|T|                Metric                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PrefixLength  | PrefixOptions |     Referenced LS Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                Forwarding Address (Optional)                -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              External Route Tag (Optional)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Referenced Link State ID (Optional)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 AS External LSA format 



bit E
The type of external metric. If bit E is set, the metric specified is a Type 2 external metric. This means the metric is considered larger than any intra-AS path. If bit E is zero, the specified metric is a Type 1 external metric. This means that it is expressed in the same units as other LSAs (i.e., the same units as the interface costs in router-LSAs).
bit F
If set, a Forwarding Address has been included in the LSA.
bit T
If set, an External Route Tag has been included in the LSA.
Metric
The cost of this route. Interpretation depends on the external type indication (bit E above).
PrefixLength, PrefixOptions and Address Prefix
Representation of the IPv6 address prefix, as described in Section Appendix A.4.1 (IPv6 Prefix Representation).
Referenced LS Type
If non-zero, an LSA with this LS type is to be associated with this LSA (see Referenced Link State ID below).
Forwarding address
A fully qualified IPv6 address (128 bits). Included in the LSA if and only if bit F has been set. If included, data traffic for the advertised destination will be forwarded to this address. It MUST NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an IPv6 Link-Local Address (Prefix FE80/10). While OSPFv3 routes are normally installed with link-local addresses, an OSPFv3 implementation advertising a forwarding address MUST advertise a global IPv6 address. This global IPv6 address may be the next-hop gateway for external prefix or may be obtained through some other method (e.g., configuration).
External Route Tag
A 32-bit field that MAY be used to communicate additional information between AS boundary routers. Included in the LSA if and only if bit T has been set.
Referenced Link State ID
Included if and only if Reference LS Type is non-zero. If included, additional information concerning the advertised external route can be found in the LSA having LS type equal to "Referenced LS Type", Link State ID equal to "Referenced Link State ID", and Advertising Router the same as that specified in the AS-external-LSA's link state header. This additional information is not used by the OSPF protocol itself. It may be used to communicate information between AS boundary routers. The precise nature of such information is outside the scope of this specification.

All, none, or some of the fields labeled Forwarding address, External Route Tag, and Referenced Link State ID MAY be present in the AS-external-LSA (as indicated by the setting of bit F, bit T, and Referenced LS Type respectively). When present, Forwarding Address always comes first, External Route Tag next, and the Referenced Link State ID last.



 TOC 

A.4.8.  NSSA-LSAs

NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated by AS boundary routers within an NSSA and describe destinations external to the AS that may or may not be propagated outside the NSSA (refer to [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.)). Other than the LS Type, their format is exactly the same as AS-external LSAs as described in Appendix A.4.7 (AS-external-LSAs).

A global IPv6 address MUST be selected as forwarding address for NSSA-LSAs that are to be propagated by NSSA area border routers. The selection should proceed the same as OSPFv2 NSSA support [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.) with additional checking to assure IPv6 link-local address are not selected.



 TOC 

A.4.9.  Link-LSAs

Link-LSAs have LS type equal to 0x0008. A router originates a separate link-LSA for each attached physical link. These LSAs have local-link flooding scope; they are never flooded beyond the associated link. 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 broadcast or NBMA link.

For details concerning the construction of Links-LSAs, see Section 4.4.3.8 (Link-LSAs).

A link-LSA's Link State ID is set equal to the originating router's Interface ID on the link.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS Age              |0|0|0|          8              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS Checksum            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rtr Priority  |                Options                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                Link-local Interface Address                 -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         # prefixes                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |             0                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |             0                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Link LSA format 



Rtr Priority
The Router Priority of the interface attaching the originating router to the link.
Options
The set of Options bits that the router would like set in the network-LSA that will be originated by the Designated Router on broadcast or NBMA links.
Link-local Interface Address
The originating router's link-local interface address on the link.
# prefixes
The number of IPv6 address prefixes contained in the LSA.

The rest of the link-LSA contains a list of IPv6 prefixes to be associated with the link.

PrefixLength, PrefixOptions and Address Prefix
Representation of an IPv6 address prefix, as described in Appendix A.4.1 (IPv6 Prefix Representation)


 TOC 

A.4.10.  Intra-Area-Prefix-LSAs

Intra-area-prefix-LSAs have LS type equal to 0x2009. A router uses intra-area-prefix-LSAs to advertise one or more IPv6 address prefixes that are associated with a local router address, an attached stub network segment, or an attached transit network segment. In IPv4, the first two were accomplished via the router's router-LSA and the last via a network-LSA. In OSPF for IPv6, all addressing information that was advertised in router-LSAs and network-LSAs has been removed and is now advertised in intra-area-prefix-LSAs. For details concerning the construction of intra-area-prefix-LSA, see Section 4.4.3.9 (Intra-Area-Prefix-LSAs).

A router can originate multiple intra-area-prefix-LSAs for each router or transit network. Each such LSA is distinguished by its unique Link State ID.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS Age              |0|0|1|            9            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS Checksum            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         # Prefixes            |     Referenced LS Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Referenced Link State ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Referenced Advertising Router                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 intra-Area-Prefix LSA format 



# prefixes
The number of IPv6 address prefixes contained in the LSA.
Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router
Identifies the router-LSA or network-LSA with which the IPv6 address prefixes should be associated. If Referenced LS Type is 0x2001, the prefixes are associated with a router-LSA, Referenced Link State ID should be 0, and Referenced Advertising Router should be the originating router's Router ID. If Referenced LS Type is 0x2002, the prefixes are associated with a network-LSA, Referenced Link State ID should be the Interface ID of the link's Designated Router, and Referenced Advertising Router should be the Designated Router's Router ID.

The rest of the intra-area-prefix-LSA contains a list of IPv6 prefixes to be associated with the router or transit link, as well as, their associated costs.

PrefixLength, PrefixOptions, and Address Prefix
Representation of an IPv6 address prefix, as described in Section Appendix A.4.1 (IPv6 Prefix Representation)
Metric
The cost of this prefix. Expressed in the same units as the interface costs in router-LSAs.


 TOC 

Appendix B.  Architectural Constants

Architectural constants for the OSPF protocol are defined in Appendix B of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.). The only difference for OSPF for IPv6 is that DefaultDestination is encoded as a prefix with length 0 (see Appendix A.4.1 (IPv6 Prefix Representation)).



 TOC 

Appendix C.  Configurable Constants

The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters.

Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters. Similarly, all routers attached to a network must agree on that network's HelloInterval and RouterDeadInterval.

Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable.



 TOC 

C.1.  Global parameters

In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below.

Router ID
This is a 32-bit number that uniquely identifies the router in the Autonomous System. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting due to a Router ID change, the router should flush its self-originated LSAs from the routing domain (see Section 14.1 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.)). Otherwise, they will persist for up to MaxAge seconds.

Because the size of the Router ID is smaller than an IPv6 address, it cannot be set to one of the router's IPv6 addresses (as is commonly done for IPv4). Possible Router ID assignment procedures for IPv6 include: a) assign the IPv6 Router ID as one of the router's IPv4 addresses or b) assign IPv6 Router IDs through some local administrative procedure (similar to procedures used by manufacturers to assign product serial numbers).

The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.



 TOC 

C.2.  Area parameters

All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of both routing protocol information and data traffic. The following items must be configured for an area:

Area ID
This is a 32-bit number that identifies the area. The Area ID of 0 is reserved for the backbone.
List of address ranges
Address ranges control the advertisement of routes across area boundaries. Each address range consists of the following items:
[IPv6 prefix, prefix length]
Describes the collection of IPv6 addresses contained in the address range.
Status
Set to either Advertise or DoNotAdvertise. Routing information is condensed at area boundaries. External to the area, at most a single route is advertised (via a inter-area-prefix-LSA) for each address range. The route is advertised if and only if the address range's Status is set to Advertise. Unadvertised ranges allow the existence of certain networks to be intentionally hidden from other areas. Status is set to Advertise by default.
ExternalRoutingCapability
Whether AS-external-LSAs will be flooded into/throughout the area. If AS-external-LSAs are excluded from the area, the area is called a stub area or NSSA. Internal to stub areas, routing to external destinations will be based solely on a default inter-area route. The backbone cannot be configured as a stub or NSSA area. Also, virtual links cannot be configured through stub or NSSA areas. For more information, see Section 3.6 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) and [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.).
StubDefaultCost
If the area has been configured as a stub area, and the router itself is an area border router, then the StubDefaultCost indicates the cost of the default inter-area-prefix-LSA that the router should advertise into the area. See Section 12.4.3.1 of [OSPFV2] (Moy, J., “OSPF Version 2,” April 1998.) for more information.
NSSATranslatorRole and TranslatorStabilityInterval
These area parameters are described in Appendix D of [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.). Additionally, an NSSA Area Border Router (ABR) is also required to allow configuration of whether or not an NSSA default route is advertised in an NSSA-LSA. If advertised, its metric and metric type are configurable. These requirements are also described in Appendix D of [NSSA] (Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option,” January 2003.).
ImportSummaries
When set to enabled, prefixes external to the area are imported into the area via the advertisement of inter-area-prefix-LSAs. When set to disabled, inter-area routes are not imported into the area. The default setting is enabled. This parameter is only valid for stub or NSSA areas.


 TOC 

C.3.  Router interface parameters

Some of the configurable router interface parameters (such as Area ID, HelloInterval, and RouterDeadInterval) actually imply properties of the attached links. Therefore, these parameters must be consistent across all the routers attached to that link. The parameters that must be configured for a router interface are:

IPv6 link-local address
The IPv6 link-local address associated with this interface. May be learned through auto-configuration.
Area ID
The OSPF area to which the attached link belongs.
Instance ID
The OSPF protocol instance associated with this OSPF interface. Defaults to 0.
Interface ID
32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some implementations it may be possible to use the MIB-II IfIndex ([INTFMIB] (McCloghrie, K. and F. Kastenholz, “The interfaces Group MIB,” June 2000.)).
IPv6 prefixes
The list of IPv6 prefixes to associate with the link. These will be advertised in intra-area-prefix-LSAs.
Interface output cost(s)
The cost of sending a packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router's router-LSA. The interface output cost MUST always be greater than 0.
RxmtInterval
The number of seconds between LSA retransmissions for adjacencies belonging to this interface. Also used when retransmitting Database Description and Link State Request packets. This should be well over the expected round-trip delay between any two routers on the attached link. The setting of this value should be conservative or needless retransmissions will result. Sample value for a local area network: 5 seconds.
InfTransDelay
The estimated number of seconds it takes to transmit a Link State Update packet over this interface. LSAs contained in the update packet must have their age incremented by this amount before transmission. This value should take into account the transmission and propagation delays of the interface. It MUST be greater than 0. Sample value for a local area network: 1 second.
Router Priority
An 8-bit unsigned integer. When two routers attached to a network both attempt to become Designated Router, the one with the highest Router Priority takes precedence. If there is still a tie, the router with the highest Router ID takes precedence. A router whose Router Priority is set to 0 is ineligible to become Designated Router on the attached link. Router Priority is only configured for interfaces to broadcast and NBMA networks.
HelloInterval
The length of time, in seconds, between Hello packets that the router sends on the interface. This value is advertised in the router's Hello packets. It MUST be the same for all routers attached to a common link. The smaller the HelloInterval, the faster topological changes will be detected. However, more OSPF routing protocol traffic will ensue. Sample value for a X.25 PDN: 30 seconds. Sample value for a local area network (LAN): 10 seconds.
RouterDeadInterval
After ceasing to hear a router's Hello packets, the number of seconds before its neighbors declare the router down. This is also advertised in the router's Hello packets in their RouterDeadInterval field. This should be some multiple of the HelloInterval (e.g., 4). This value again MUST be the same for all routers attached to a common link.
LinkLSASuppression
Indicates whether or not origination of a Link-LSA is suppressed. If set to "enabled" and the interface type is not broadcast or NBMA, the router will not originate a Link-LSA for the link. 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 4.8.2 (The next hop calculation)). The default value is "disabled" for interface types described in this specification. It is implicitly "disabled" if the interface type is broadcast or NBMA. Future interface types MAY specify a different default.


 TOC 

C.4.  Virtual link parameters

Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as a point-to-point link with no global IPv6 addresses in the graph for the backbone. The virtual link must be configured in both of the area border routers.

A virtual link appears in router-LSAs (for the backbone) as if it were a separate router interface to the backbone. As such, it has most of the parameters associated with a router interface (see Appendix C.3 (Router interface parameters)). Virtual links do not have link-local addresses, but instead use one of the router's global-scope IPv6 addresses as the IP source in OSPF protocol packets it sends on the virtual link. Router Priority is not used on virtual links. Interface output cost is not configured on virtual links, but is dynamically set to be the cost of the transit area intra-area path between the two endpoint routers. The parameter RxmtInterval may be configured and should be well over the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too long.

A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint and the (non-backbone) area which the virtual link traverses (referred to as the virtual link's transit area). Virtual links cannot be configured through stub or NSSA areas. Additionally, an Instance ID may be configured for virtual links from different protocol instances in order to utilize the same transit area (without requiring different router IDs for demultiplexing).



 TOC 

C.5.  NBMA network parameters

OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA listing all routers attached to the NBMA network.

However, due to the lack of broadcast capabilities, it may be necessary to use configuration parameters in the Designated Router selection. These parameters will only need to be configured in those routers that are themselves eligible to become Designated Router (i.e., those router's whose Router Priority for the network is non-zero), and then only if no automatic procedure for discovering neighbors exists:

List of all other attached routers
The list of all other routers attached to the NBMA network. Each router is configured with its Router ID and IPv6 link-local address on the network. Also, for each router listed, that router's eligibility to become Designated Router must be defined. When an interface to an NBMA network first comes up, the router only sends Hello packets to those neighbors eligible to become Designated Router until such time that a Designated Router is elected.
PollInterval
If a neighboring router has become inactive (Hello packets have not been seen for RouterDeadInterval seconds), it may still be necessary to send Hello packets to the dead neighbor. These Hello packets will be sent at the reduced rate PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network: 2 minutes.


 TOC 

C.6.  Point-to-Multipoint network parameters

On Point-to-Multipoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the Point-to-Multipoint network. Each neighbor is configured with its Router ID and IPv6 link-local address on the network. Designated Routers are not elected on Point-to-Multipoint networks, so the Designated Router eligibility of configured neighbors is not defined.



 TOC 

C.7.  Host route parameters

Host prefixes are advertised in intra-area-prefix-LSAs. They indicate either local router addresses, router interfaces to point-to-point networks, looped router interfaces, or IPv6 hosts that are directly connected to the router (e.g., via a PPP connection). For each host directly connected to the router, the following items must be configured:

Host IPv6 prefix
An IPv6 prefix belonging to the directly connected host. This must not be a valid IPv6 global prefix.
Cost of link to host
The cost of sending a packet to the host, in terms of the link state metric. However, since the host probably has only a single connection to the Internet, the actual configured cost(s) in many cases is unimportant (i.e., will have no effect on routing).
Area ID
The OSPF area to which the host's prefix belongs.


 TOC 

Appendix D.  Change Log (To Be Removed Prior To Publication)



 TOC 

D.1.  Changes from RFC 2740 to 00 Version

The section contains list of changes from RFC 2740 [OSPFV3] (Coltun, R., Ferguson, D., and J. Moy, “OSPF for IPv6,” December 1999.):



 TOC 

D.2.  Changes from the 00 Version to the 01 Version

The section contains list of changes from version 00 to version 01:



 TOC 

D.3.  Changes from the 01 Version to the 02 Version

The section contains list of changes from version 01 to version 02:



 TOC 

D.4.  Changes from the 02 Version to the 03 Version

The section contains list of changes from version 02 to version 03:



 TOC 

D.5.  Changes from the 03 Version to the 04 Version

The section contains list of changes from version 03 to version 04:



 TOC 

D.6.  Changes from the 04 Version to the 05 Version

The section contains list of changes from version 04 to version 05:



 TOC 

D.7.  Changes from the 05 Version to the 06 Version

The section contains list of changes from version 05 to version 06:



 TOC 

D.8.  Changes from the 06 Version to the 07 Version

The section contains list of changes from version 06 to version 07:



 TOC 

D.9.  Changes from the 07 Version to the 08 Version

The section contains list of changes from version 07 to version 08:



 TOC 

D.10.  Changes from the 08 Version to the 09 Version

The section contains list of changes from version 08 to version 09:



 TOC 

D.11.  Changes from the 09 Version to the 10 Version

The section contains list of changes from version 09 to version 10:



 TOC 

D.12.  Changes from the 10 Version to the 11 Version

The section contains list of changes from version 10 to version 11:



 TOC 

D.13.  Changes from the 11 Version to the 12 Version

The section contains list of changes from version 11 to version 12:



 TOC 

D.14.  Changes from the 12 Version to the 13 Version

The section contains list of changes from version 12 to version 13:



 TOC 

D.15.  Changes from the 13 Version to the 14 Version

The section contains list of changes from version 13 to version 14:



 TOC 

D.16.  Changes from the 14 Version to the 15 Version

The section contains list of changes from version 14 to version 15:



 TOC 

D.17.  Changes from the 15 Version to the 16 Version

The section contains list of changes from version 15 to version 16:



 TOC 

D.18.  Changes from the 16 Version to the 17 Version

The section contains list of changes from version 16 to version 17:



 TOC 

D.19.  Changes from the 17 Version to the 18 Version

The section contains list of changes from version 17 to version 18:



 TOC 

D.20.  Changes from the 18 Version to the 19 Version

The section contains list of changes from version 18 to version 19:



 TOC 

D.21.  Changes from the 19 Version to the 20 Version

The section contains list of changes from version 19 to version 20:



 TOC 

D.22.  Changes from the 20 Version to the 21 Version

The section contains list of changes from version 20 to version 21:



 TOC 

D.23.  Changes from the 21 Version to the 22 Version

The section contains list of changes from version 21 to version 22:



 TOC 

D.24.  Changes from the 22 Version to the 23 Version

The section contains list of changes from version 22 to version 23:



 TOC 

Authors' Addresses

  Rob Coltun
  Acoustra Productions
  3204 Brooklawn Terrace
  Chevy Chase, MD 20815
  USA
Email:  undisclosed
  
  Dennis Ferguson
  Juniper Networks
  1194 N. Mathilda Avenue
  Sunnyvale, CA 94089
  USA
Email:  dennis@juniper.net
  
  John Moy
  Sycamore Networks, Inc
  10 Elizabeth Drive
  Chelmsford, MA 01824
  USA
Email:  jmoy@sycamorenet.com
  
  Acee Lindem
  Redback Networks
  102 Carric Bend Court
  Cary, NC 27519
  USA
Email:  acee@redback.com


 TOC 

Full Copyright Statement

Intellectual Property