Skip to main content

2. Differences from OSPF for IPv4

Most of the algorithms from OSPF for IPv4 [OSPFV2] have been preserved in OSPF for IPv6. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.

The following subsections describe the differences between this document and [OSPFV2].

IPv6 uses the term "link" to indicate "a communication facility or medium over which nodes can communicate at the link layer" ([IPV6]). "Interfaces" connect to links. Multiple IPv6 subnets can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IPv6 subnet (IPv6 prefix).

For this reason, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet. The terms "network" and "subnet" used in the IPv4 OSPF specification ([OSPFV2]) should generally be replaced by link. Likewise, an OSPF interface now connects to a link instead of an IP subnet.

This change affects the receiving of OSPF protocol packets, the contents of Hello packets, and the contents of network-LSAs.

2.2. Removal of Addressing Semantics​

In OSPF for IPv6, addressing semantics have been removed from the OSPF protocol packets and the main LSA types, leaving a network-protocol-independent core. In particular:

  • IPv6 addresses are not present in OSPF packets, except in LSA payloads carried by the Link State Update packets. See Section 2.7 for details.

  • Router-LSAs and network-LSAs no longer contain network addresses, but simply express topology information. See Section 2.8 for details.

  • OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the IPv4 size of 32 bits. They can no longer be assigned as (IPv6) addresses.

  • Neighboring routers are now always identified by Router ID. Previously, they had been identified by an IPv4 address on broadcast, NBMA (Non-Broadcast Multi-Access), and point-to-multipoint links.

2.3. Addition of Flooding Scope​

Flooding scope for LSAs has been generalized and is now explicitly coded in the LSA's LS type field. There are now three separate flooding scopes for LSAs:

  • Link-local scope. LSA is only flooded on the local link and no further. Used for the new link-LSA. See Section 4.4.3.8 for details.

  • Area scope. LSA is only flooded throughout a single OSPF area. Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs.

  • AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in router-LSAs for regular areas.

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.

IPv6 link-local addresses are for use on a single link, for purposes of neighbor discovery, auto-configuration, etc. IPv6 routers do not forward IPv6 datagrams having link-local source addresses [IP6ADDR]. Link-local unicast addresses are assigned from the IPv6 address range FE80/10.

OSPF for IPv6 assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical links [IP6ADDR]. On all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as the source address. A router learns the link-local addresses of all other routers attached to its links and uses these addresses as next-hop information during packet forwarding.

On virtual links, a global scope IPv6 address MUST be used as the source address for OSPF protocol packets.

Link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8). However, link-local addresses are not allowed in other OSPF LSA types. In particular, link-local addresses MUST NOT be advertised in inter-area-prefix-LSAs (Section 4.4.3.4), AS-external-LSAs (Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix-LSAs (Section 4.4.3.9).

2.6. Authentication Changes​

In OSPF for IPv6, authentication has been removed from the OSPF protocol. The "AuType" and "Authentication" fields have been removed from the OSPF packet header, and all authentication-related fields have been removed from the OSPF area and interface data structures.

When running over IPv6, OSPF relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/confidentiality of routing exchanges.

Protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]), covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1).

2.7. Packet Format Changes​

OSPF for IPv6 runs directly over IPv6. Aside from this, all addressing semantics have been removed from the OSPF packet headers, making it essentially "network-protocol-independent". All addressing information is now contained in the various LSA types only.

In detail, changes in OSPF packet format consist of the following:

  • The OSPF version number has been incremented from 2 to 3.

  • The Options field in Hello packets and Database Description packets has been expanded to 24 bits.

  • The Authentication and AuType fields have been removed from the OSPF packet header (see Section 2.6).

  • The Hello packet now contains no address information at all. Rather, it now includes an Interface ID that the originating router has assigned to uniquely identify (among its own interfaces) its interface to the link. This Interface ID will be used as the network-LSA's Link State ID if the router becomes the Designated Router on the link.

  • Two Options bits, the "R-bit" and the "V6-bit", have been added to the Options field for processing router-LSAs during the SPF calculation (see Appendix A.2). If the "R-bit" is clear, an OSPF speaker can participate in OSPF topology distribution without being used to forward transit traffic; this can be used in multi-homed hosts that want to participate in the routing protocol. The V6-bit specializes the R-bit; if the V6-bit is clear, an OSPF speaker can participate in OSPF topology distribution without being used to forward IPv6 datagrams. If the R-bit is set and the V6-bit is clear, IPv6 datagrams are not forwarded but datagrams belonging to another protocol family may be forwarded.

  • The OSPF packet header now includes an "Instance ID" that allows multiple OSPF protocol instances to be run on a single link (see Section 2.4).

2.8. LSA Format Changes​

All addressing semantics have been removed from the LSA header, router-LSAs, and network-LSAs. These two LSAs now describe the routing domain's topology in a network-protocol-independent manner. New LSAs have been added to distribute IPv6 address information and data required for next-hop resolution. The names of some of IPv4's LSAs have been changed to be more consistent with each other.

In detail, changes in LSA format consist of the following:

  • The Options field has been removed from the LSA header, expanded to 24 bits, and moved into the body of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs. See Appendix A.2 for details.

  • The LSA Type field has been expanded (into the former Options space) to 16 bits, with the upper three bits encoding flooding scope and the handling of unknown LSA types (see Section 2.9).

  • Addresses in LSAs are now expressed as [prefix, prefix length] instead of [address, mask] (see Appendix A.4.1). The default route is expressed as a prefix with length 0.

  • Router-LSAs and network-LSAs now have no address information and are network protocol independent.

  • Router interface information MAY be spread across multiple router-LSAs. Receivers MUST concatenate all the router-LSAs originated by a given router when running the SPF calculation.

  • A new LSA called the link-LSA has been introduced. Link-LSAs have link-local flooding scope; they are never flooded beyond the link with which they are associated. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link, 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link, and 3) they allow the router to advertise a collection of Options bits to associate with the network-LSA that will be originated for the link. See Section 4.4.3.8 for details.

  • In IPv4, the router-LSA carries a router's IPv4 interface addresses, the IPv4 equivalent of link-local addresses. These are only used when calculating next hops during the OSPF routing calculation (see Section 16.1.1 of [OSPFV2]), so they do not need to be flooded past the local link. Hence, using link-LSAs to distribute these addresses is more efficient. Note that link-local addresses cannot be learned through the reception of Hellos in all cases. On NBMA links, next-hop routers do not necessarily exchange Hellos. Rather, these routers learn of each other's existence by way of the Designated Router (DR).

  • The Options field in the network LSA is set to the logical OR of the Options that each router on the link advertises in its link-LSA.

  • Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs". Type-4 summary LSAs have been renamed "inter-area-router-LSAs".

  • The Link State ID in inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA-LSAs, and AS-external-LSAs has lost its addressing semantics and now serves solely to identify individual pieces of the Link State Database. All addresses or Router IDs that were formerly expressed by the Link State ID are now carried in the LSA bodies.

  • Network-LSAs and link-LSAs are the only LSAs whose Link State ID carries additional meaning. For these LSAs, the Link State ID is always the Interface ID of the originating router on the link being described. For this reason, network-LSAs and link-LSAs are now the only LSAs whose size cannot be limited: a network-LSA MUST list all routers connected to the link and a link-LSA MUST list all of a router's addresses on the link.

  • A new LSA called the intra-area-prefix-LSA has been introduced. This LSA carries all IPv6 prefix information that in IPv4 is included in router-LSAs and network-LSAs. See Section 4.4.3.9 for details.

  • Inclusion of a forwarding address or external route tag in AS-external-LSAs is now optional. In addition, AS-external-LSAs can now reference another LSA, for inclusion of additional route attributes that are outside the scope of the OSPF protocol. For example, this reference could be used to attach BGP path attributes to external routes.

2.9. Handling Unknown LSA Types​

Handling of unknown LSA types has been made more flexible so that, based on the LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood. This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see the U-bit in Appendix A.4.2.1).

The IPv4 OSPF behavior of simply discarding unknown types is unsupported due to the desire to mix router capabilities on a single link. Discarding unknown types causes problems when the Designated Router supports fewer options than the other routers on the link.

2.10. Stub/NSSA Area Support​

In OSPF for IPv4, stub and NSSA areas were designed to minimize link-state database and routing table sizes for the areas' internal routers. This allows routers with minimal resources to participate in even very large OSPF routing domains.

In OSPF for IPv6, the concept of stub and NSSA areas is retained. In IPv6, of the mandatory LSA types, stub areas carry only router-LSAs, network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area-prefix-LSAs. NSSA areas are restricted to these types and, of course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs.

2.11. Identifying Neighbors by Router ID​

In OSPF for IPv6, neighboring routers on a given link are always identified by their OSPF Router ID. This contrasts with the IPv4 behavior where neighbors on point-to-point networks and virtual links are identified by their Router IDs while neighbors on broadcast, NBMA, and point-to-multipoint links are identified by their IPv4 interface addresses.

This change affects the reception of OSPF packets (see Section 8.2 of [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]), and the reception of Hello packets (Section 10.5 of [OSPFV2]).

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

Last updated on