Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2740

OSPF for IPv6

Pages: 80
Obsoleted by:  5340
Part 1 of 3 – Pages 1 to 20
None   None   Next

ToP   noToC   RFC2740 - Page 1
Network Working Group                                          R. Coltun
Requests for Comments: 2740                                Siara Systems
Category: Standards Track                                    D. Ferguson
                                                        Juniper Networks
                                                                  J. Moy
                                                       Sycamore Networks
                                                           December 1999


                             OSPF for IPv6

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.
ToP   noToC   RFC2740 - Page 2
   All of OSPF for IPv4's optional capabilities, including on-demand
   circuit support, NSSA areas, and the multicast extensions to OSPF
   (MOSPF) are also supported in OSPF for IPv6.

Table of Contents

1 Introduction ........................................... 4 1.1 Terminology ............................................ 4 2 Differences from OSPF for IPv4 ......................... 4 2.1 Protocol processing per-link, not per-subnet ........... 5 2.2 Removal of addressing semantics ........................ 5 2.3 Addition of Flooding scope ............................. 5 2.4 Explicit support for multiple instances per link ....... 6 2.5 Use of link-local addresses ............................ 6 2.6 Authentication changes ................................. 7 2.7 Packet format changes .................................. 7 2.8 LSA format changes ..................................... 8 2.9 Handling unknown LSA types ............................ 10 2.10 Stub area support ..................................... 10 2.11 Identifying neighbors by Router ID .................... 11 3 Implementation details ................................ 11 3.1 Protocol data structures .............................. 12 3.1.1 The Area Data structure ............................... 13 3.1.2 The Interface Data structure .......................... 13 3.1.3 The Neighbor Data Structure ........................... 14 3.2 Protocol Packet Processing ............................ 15 3.2.1 Sending protocol packets .............................. 15 3.2.1.1 Sending Hello packets ................................. 16 3.2.1.2 Sending Database Description Packets .................. 17 3.2.2 Receiving protocol packets ............................ 17 3.2.2.1 Receiving Hello Packets ............................... 19 3.3 The Routing table Structure ........................... 19 3.3.1 Routing table lookup .................................. 20 3.4 Link State Advertisements ............................. 20 3.4.1 The LSA Header ........................................ 21 3.4.2 The link-state database ............................... 22 3.4.3 Originating LSAs ...................................... 22 3.4.3.1 Router-LSAs ........................................... 25 3.4.3.2 Network-LSAs .......................................... 27 3.4.3.3 Inter-Area-Prefix-LSAs ................................ 28 3.4.3.4 Inter-Area-Router-LSAs ................................ 29 3.4.3.5 AS-external-LSAs ...................................... 29 3.4.3.6 Link-LSAs ............................................. 31 3.4.3.7 Intra-Area-Prefix-LSAs ................................ 32 3.5 Flooding .............................................. 35 3.5.1 Receiving Link State Update packets ................... 36 3.5.2 Sending Link State Update packets ..................... 36 3.5.3 Installing LSAs in the database ....................... 38
ToP   noToC   RFC2740 - Page 3
   3.6      Definition of self-originated LSAs .................... 39
   3.7      Virtual links ......................................... 39
   3.8      Routing table calculation ............................. 39
   3.8.1    Calculating the shortest path tree for an area ........ 40
   3.8.1.1  The next hop calculation .............................. 41
   3.8.2    Calculating the inter-area routes ..................... 42
   3.8.3    Examining transit areas' summary-LSAs ................. 42
   3.8.4    Calculating AS external routes ........................ 42
   3.9      Multiple interfaces to a single link .................. 43
            References ............................................ 44
   A.       OSPF data formats ..................................... 46
   A.1      Encapsulation of OSPF packets ......................... 46
   A.2      The Options field ..................................... 47
   A.3      OSPF Packet Formats ................................... 48
   A.3.1    The OSPF packet header ................................ 49
   A.3.2    The Hello packet ...................................... 50
   A.3.3    The Database Description packet ....................... 52
   A.3.4    The Link State Request packet ......................... 54
   A.3.5    The Link State Update packet .......................... 55
   A.3.6    The Link State Acknowledgment packet .................. 56
   A.4      LSA formats ........................................... 57
   A.4.1    IPv6 Prefix Representation ............................ 58
   A.4.1.1  Prefix Options ........................................ 58
   A.4.2    The LSA header ........................................ 59
   A.4.2.1  LS type ............................................... 60
   A.4.3    Router-LSAs ........................................... 61
   A.4.4    Network-LSAs .......................................... 64
   A.4.5    Inter-Area-Prefix-LSAs ................................ 65
   A.4.6    Inter-Area-Router-LSAs ................................ 66
   A.4.7    AS-external-LSAs ...................................... 67
   A.4.8    Link-LSAs ............................................. 69
   A.4.9    Intra-Area-Prefix-LSAs ................................ 71
   B.       Architectural Constants ............................... 73
   C.       Configurable Constants ................................ 73
   C.1      Global parameters ..................................... 73
   C.2      Area parameters ....................................... 74
   C.3      Router interface parameters ........................... 75
   C.4      Virtual link parameters ............................... 77
   C.5      NBMA network parameters ............................... 77
   C.6      Point-to-MultiPoint network parameters ................ 78
   C.7      Host route parameters ................................. 78
            Security Considerations ............................... 79
            Authors' Addresses .................................... 79
            Full Copyright Statement .............................. 80
ToP   noToC   RFC2740 - Page 4

1. Introduction

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. This document is organized as follows. Section 2 describes the differences between OSPF for IPv4 and OSPF for IPv6 in detail. Section 3 provides implementation details for the changes. Appendix A gives the OSPF for IPv6 packet and LSA formats. Appendix B lists the OSPF architectural constants. Appendix C describes configuration parameters.

1.1. Terminology

This document attempts to use terms from both the OSPF for IPv4 specification ([Ref1]) and the IPv6 protocol specifications ([Ref14]). This has produced a mixed result. Most of the terms used both by OSPF and IPv6 have roughly the same meaning (e.g., interfaces). However, there are a few conflicts. IPv6 uses "link" similarly to IPv4 OSPF's "subnet" or "network". In this case, we have chosen to use IPv6's "link" terminology. "Link" replaces OSPF's "subnet" and "network" in most places in this document, although OSPF's Network-LSA remains unchanged (and possibly unfortunately, a new Link-LSA has also been created). The names of some of the OSPF LSAs have also changed. See Section 2.8 for details.

2. Differences from OSPF for IPv4

Most of the algorithms from OSPF for IPv4 [Ref1] have preserved in OSPF for IPv6. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. The following subsections describe the differences between this document and [Ref1].
ToP   noToC   RFC2740 - Page 5

2.1. Protocol processing per-link, not per-subnet

IPv6 uses the term "link" to indicate "a communication facility or medium over which nodes can communicate at the link layer" ([Ref14]). "Interfaces" connect to links. Multiple IP subnets can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IP subnet (IPv6 prefix). For this reason, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet. The terms "network" and "subnet" used in the IPv4 OSPF specification ([Ref1]) should generally be relaced by link. Likewise, an OSPF interface now connects to a link instead of an IP subnet, etc. This change affects the receiving of OSPF protocol packets, and the contents of Hello Packets and Network-LSAs.

2.2. Removal of addressing semantics

In OSPF for IPv6, addressing semantics have been removed from the OSPF protocol packets and the main LSA types, leaving a network- protocol-independent core. In particular: o IPv6 Addresses are not present in OSPF packets, except in LSA payloads carried by the Link State Update Packets. See Section 2.7 for details. o Router-LSAs and Network-LSAs no longer contain network addresses, but simply express topology information. See Section 2.8 for details. o OSPF Router IDs, Area IDs and LSA Link State IDs remain at the IPv4 size of 32-bits. They can no longer be assigned as (IPv6) addresses. o Neighboring routers are now always identified by Router ID, where previously they had been identified by IP address on broadcast and NBMA "networks".

2.3. Addition of Flooding scope

Flooding scope for LSAs has been generalized and is now explicitly coded in the LSA's LS type field. There are now three separate flooding scopes for LSAs:
ToP   noToC   RFC2740 - Page 6
   o   Link-local scope. LSA is flooded only on the local link, and
       no further. Used for the new Link-LSA (see Section A.4.8).

   o   Area scope. LSA is flooded throughout a single OSPF area
       only. Used for Router-LSAs, Network-LSAs, Inter-Area-Prefix-
       LSAs, Inter-Area-Router-LSAs and Intra-Area-Prefix-LSAs.

   o   AS scope. LSA is flooded throughout the routing domain. Used
       for AS-external-LSAs.

2.4. Explicit support for multiple instances per link

OSPF now supports the ability to run multiple OSPF protocol instances on a single link. For example, this may be required on a NAP segment shared between several providers -- providers may be running separate OSPF routing domains that want to remain separate even though they have one or more physical network segments (i.e., links) in common. In OSPF for IPv4 this was supported in a haphazard fashion using the authentication fields in the OSPF for IPv4 header. Another use for running multiple OSPF instances is if you want, for one reason or another, to have a single link 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 structures. Instance ID solely affects the reception of OSPF packets.

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 [Ref15]. Link-local unicast addresses are assigned from the IPv6 address range FF80/10. OSPF for IPv6 assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical segments. On all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as source. 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, global scope or site-local IP addresses must be used as the source for OSPF protocol packets.
ToP   noToC   RFC2740 - Page 7
   Link-local addresses appear in OSPF Link-LSAs (see Section 3.4.3.6).
   However, link-local addresses are not allowed in other OSPF LSA
   types.  In particular, link-local addresses must not be advertised in
   inter-area-prefix-LSAs (Section 3.4.3.3), AS-external-LSAs (Section
   3.4.3.5) or intra-area-prefix-LSAs (Section 3.4.3.7).

2.6. Authentication changes

In OSPF for IPv6, authentication has been removed from OSPF itself. The "AuType" and "Authentication" fields have been removed from the OSPF packet header, and all authentication related fields have been removed from the OSPF area and interface structures. When running over IPv6, OSPF relies on the IP Authentication Header (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to ensure integrity and authentication/confidentiality of routing exchanges. Protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo- header (see Section 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: o The OSPF version number has been increased from 2 to 3. o The Options field in Hello Packets and Database description Packet has been expanded to 24-bits. o The Authentication and AuType fields have been removed from the OSPF packet header (see Section 2.6). o The Hello packet now contains no address information at all, and includes an Interface ID which the originating router has assigned to uniquely identify (among its own interfaces) its interface to the link. This Interface ID becomes the Netowrk-LSA's Link State ID, should the router become Designated-Router on the link.
ToP   noToC   RFC2740 - Page 8
   o  Two option bits, the "R-bit" and the "V6-bit", have been added to
      the  Options field for processing Router-LSAs during the SPF
      calculation (see Section 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 diagrams
      belonging to another protocol family may be forwarded.

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

2.8. LSA format changes

All addressing semantics have been removed from the LSA header, and from Router-LSAs and Network-LSAs. These two LSAs now describe the routing domain's topology in a network-protocol-independent manner. New LSAs have been added to distribute IPv6 address information, and data required for next hop resolution. The names of some of IPv4's LSAs have been changed to be more consistent with each other. In detail, changes in LSA format consist of the following: o The Options field has been removed from the LSA header, expanded to 24 bits, and moved into the body of Router-LSAs, Network-LSAs, Inter-Area-Router-LSAs and Link-LSAs. See Section A.2 for details. o The LSA Type field has been expanded (into the former Options space) to 16 bits, with the upper three bits encoding flooding scope and the handling of unknown LSA types (see Section 2.9). o Addresses in LSAs are now expressed as [prefix, prefix length] instead of [address, mask] (see Section A.4.1). The default route is expressed as a prefix with length 0. o The Router and Network LSAs now have no address information, and are network-protocol-independent. o Router interface information may be spread across multiple Router LSAs. Receivers must concatenate all the Router-LSAs originated by a given router when running the SPF calculation.
ToP   noToC   RFC2740 - Page 9
   o  A new LSA called the Link-LSA has been introduced. The LSAs have
      local-link flooding scope; they are never flooded beyond the link
      that they are associated with. Link-LSAs have three purposes: 1)
      they provide the router's link-local address to all other routers
      attached to the link, 2) they inform other routers attached to the
      link of a list of IPv6 prefixes to associate with the link and 3)
      they allow the router to assert a collection of Options bits to
      associate with the Network-LSA that will be originated for the
      link.  See Section A.4.8 for details.

      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 [Ref1]), 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, but rather learn of each other's existence by way of the
      Designated Router.

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

   o  Type-3 summary-LSAs have been renamed "Inter-Area-Prefix-LSAs".
      Type-4 summary LSAs have been renamed "Inter-Area-Router-LSAs".

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

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

   o  A new LSA called the Intra-Area-Prefix-LSA has been introduced.
      This LSA carries all IPv6 prefix information that in IPv4 is
      included in Router-LSAs and Network-LSAs.  See Section A.4.9 for
      details.
ToP   noToC   RFC2740 - Page 10
   o  Inclusion of a forwarding address in AS-external-LSAs is now
      optional, as is the inclusion of an external route tag (see
      [Ref5]). 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 itself. For example, this can be
      used to attach BGP path attributes to external routes as proposed
      in [Ref10].

2.9. Handling unknown LSA types

Handling of unknown LSA types has been made more flexible so that, based on LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood (desirable for things like the proposed External- Attributes-LSA in [Ref10]). This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see Section A.4.2.1). The IPv4 OSPF behavior of simply discarding unknown types is unsupported due to the desire to mix router capabilities on a single link. Discarding unknown types causes problems when the Designated Router supports fewer options than the other routers on the link.

2.10. Stub area support

In OSPF for IPv4, stub 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 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. This is the IPv6 equivalent of the LSA types carried in IPv4 stub areas: router-LSAs, network-LSAs and type 3 summary-LSAs. 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 Section 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 may 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.
ToP   noToC   RFC2740 - Page 11

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, and 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 [Ref1]), the lookup of neighbors (Section 10 of [Ref1]) and the reception of Hello Packets (Section 10.5 of [Ref1]). The Router ID of 0.0.0.0 is reserved, and should not be used.

3. Implementation details

When going from IPv4 to IPv6, the basic OSPF mechanisms remain unchanged from those documented in [Ref1]. These mechanisms are briefly outlined in Section 4 of [Ref1]. 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, through 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, and 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 [Ref1] remains completely unchanged for IPv6: o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 of [Ref1], namely: Hello, Database Description, Link State Request, Link State Update and Link State Acknowledgment packets. While in some cases (e.g., Hello packets) their format has changed somewhat, the functions of the various packet types remains the same. o The system requirements for an OSPF implementation remain unchanged, although OSPF for IPv6 requires an IPv6 protocol stack (from the network layer on down) since it runs directly over the IPv6 network layer.
ToP   noToC   RFC2740 - Page 12
   o  The discovery and maintenance of neighbor relationships, and the
      selection and establishment of adjacencies remain the same. This
      includes election of the Designated Router and Backup Designated
      Router on broadcast and NBMA links. These mechanisms are described
      in Sections 7, 7.1, 7.2, 7.3, 7.4 and 7.5 of [Ref1].

   o  The link types (or equivalently, interface types) supported by
      OSPF remain unchanged, namely: point-to-point, broadcast, NBMA,
      Point-to-MultiPoint and virtual links.

   o  The interface state machine, including the list of OSPF interface
      states and events, and the Designated Router and Backup Designated
      Router election algorithm, remain unchanged.  These are described
      in Sections 9.1, 9.2, 9.3 and 9.4 of [Ref1].

   o  The neighbor state machine, including the list of OSPF neighbor
      states and events, remain unchanged. These are described in
      Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1].

   o  Aging of the link-state database, as well as flushing LSAs from
      the routing domain through the premature aging process, remains
      unchanged from the description in Sections 14 and 14.1 of [Ref1].

   However, some OSPF protocol mechanisms have changed, as outlined in
   Section 2 above. These changes are explained in detail in the
   following subsections, making references to the appropriate sections
   of [Ref1].

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

3.1. Protocol data structures

The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database and the routing table. The top-level data structures for IPv6 remain those listed in Section 5 of [Ref1], with the following modifications: o All LSAs with known LS type and AS flooding scope appear in the top-level data structure, instead of belonging to a specific area or link. AS-external-LSAs are the only LSAs defined by this specification which have AS flooding scope. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized) and AS flooding scope also appear in the top-level data structure.
ToP   noToC   RFC2740 - Page 13

3.1.1. The Area Data structure

The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [Ref1]. 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. IPv6 routers implementing MOSPF add group- membership-LSAs to the area data structure. Type-7-LSAs belong to an NSSA area's data structure.

3.1.2. The Interface Data structure

In OSPF for IPv6, an interface connects a router to a link. The IPv6 interface structure modifies the IPv4 interface structure (as defined in Section 9 of [Ref1]) 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 ([Ref3]) 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. Instance ID Every interface is assigned an Instance ID. This should default to 0, and 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 given an Instance ID of 0, by assigning 0 as the Instance ID of all its routers' interfaces to the ethernet. An Instance ID of 1 is assigned to the other routers' interfaces to the ethernet. The OSPF transmit and receive processing (see Section 3.2) will then keep the two communities separate. List of LSAs with link-local scope All LSAs with link-local scope and which were originated/flooded on the link belong to the interface structure which connects to the link. This includes the collection of the link's link-LSAs.
ToP   noToC   RFC2740 - Page 14
   List of LSAs with unknown LS type
      All LSAs with unknown LS type and U-bit set to 0 (if unrecognized,
      treat the LSA as if it had link-local flooding scope) are kept in
      the data structure for the interface that received the LSA.

   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 site-local or 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
   [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to
   ensure integrity and authentication/confidentiality of routing
   exchanges.  For that reason, AuType and Authentication key are not
   associated with IPv6 OSPF interfaces.

   Interface states, events, and the interface state machine remain
   unchanged from IPv4, and are documented in Sections 9.1, 9.2 and 9.3
   of [Ref1] respectively. The Designated Router and Backup Designated
   Router election algorithm also remains unchanged from the IPv4
   election in Section 9.4 of [Ref1].

3.1.3. The Neighbor Data Structure

The neighbor structure performs the same function in both IPv6 and IPv4. Namely, it collects all information required to form an adjacency between two routers, if 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 [Ref1] 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 link to the neighbor or b) advertising a link to a network where the neighbor has become Designated Router.
ToP   noToC   RFC2740 - Page 15
   Neighbor IP address
      Except on virtual links, the neighbor's IP address will be an IPv6
      link-local address.

   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 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, and are documented in Sections 10.1, 10.2 and
   10.3 of [Ref1] respectively. The decision as to which adjacencies to
   form also remains unchanged from the IPv4 logic documented in Section
   10.4 of [Ref1].

3.2. Protocol Packet Processing

OSPF for IPv6 runs directly over IPv6's network layer. As such, it is encapsulated in one or more IPv6 headers, with the Next Header field of the immediately encapsulating IPv6 header set to the value 89. As for IPv4, in 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 IPv4, encoded by the Type field of the standard OSPF packet header.

3.2.1. Sending protocol packets

When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Section A.3.1) as follows: Version # Set to 3, the version number of the protocol as documented in this specification. Type The type of OSPF packet, such as Link state Update or Hello Packet. Packet length The length of the entire OSPF packet in bytes, including the standard OSPF packet header.
ToP   noToC   RFC2740 - Page 16
   Router ID
      The identity of the router itself (who is originating the packet).

   Area ID
      The OSPF area that the packet is being sent into.

   Instance ID
      The OSPF Instance ID associated with the interface that the packet
      is being sent out of.

   Checksum
      The standard IPv6 16-bit one's complement checksum, covering the
      entire OSPF packet and prepended IPv6 pseudo-header (see Section
      A.3.1).

   Selection of OSPF routing protocol packets' IPv6 source and
   destination addresses is performed identically to the IPv4 logic in
   Section 8.1 of [Ref1]. 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 [Ref1] respectively. Sending
   Hello Packets is documented in Section 3.2.1.1, and the sending of
   Database Description Packets in Section 3.2.1.2. The sending of Link
   State Update Packets is documented in Section 3.5.2.

3.2.1.1. Sending Hello packets
IPv6 changes the way OSPF Hello packets are sent in the following ways (compare to Section 9.5 of [Ref1]): o Before the Hello Packet is sent out an interface, the interface's Interface ID must be copied into the Hello Packet. o The Hello Packet no longer contains an IP network mask, as OSPF for IPv6 runs per-link instead of per-subnet. o The choice of Designated Router and Backup Designated Router are now indicated within Hellos by their Router IDs, instead of by their IP interface addresses. Advertising the Designated Router (or Backup Designated Router) as 0.0.0.0 indicates that the Designated Router (or Backup Designated Router) has not yet been chosen.
ToP   noToC   RFC2740 - Page 17
   o  The Options field within Hello packets has moved around, getting
      larger in the process. More options bits are now possible. Those
      that must be set correctly in Hello packets are: The E-bit is set
      if and only if the interface attaches to a non-stub area, the N-
      bit is set if and only if the interface attaches to an NSSA area
      (see [Ref9]), and the DC- bit is set if and only if the router
      wishes to suppress the sending of future Hellos over the interface
      (see [Ref11]). Unrecognized bits in the Hello Packet's Options
      field should be cleared.

   Sending Hello packets on NBMA networks proceeds for IPv6 in exactly
   the same way as for IPv4, as documented in Section 9.5.1 of [Ref1].

3.2.1.2. Sending Database Description Packets
The sending of Database Description packets differs from Section 10.8 of [Ref1] in the following ways: o The Options field within Database Description packets has moved around, getting larger in the process. More options bits are now possible. Those that must be set correctly in Database Description packets are: The MC-bit is set if and only if the router is forwarding multicast datagrams according to the MOSPF specification in [Ref7], and the DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [Ref11]). Unrecognized bits in the Database Description Packet's Options field should be cleared.

3.2.2. Receiving protocol packets

Whenever an OSPF protocol packet is received by the router it is marked with the interface it was received on. For routers that have virtual links configured, it may not be immediately obvious which interface to associate the packet with. For example, consider the Router RT11 depicted in Figure 6 of [Ref1]. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link. In order for the packet to be passed to OSPF for processing, the following tests must be performed on the encapsulating IPv6 headers: o The packet's IP destination address must be one of the IPv6 unicast addresses associated with the receiving interface (this includes link-local addresses), or one of the IP multicast addresses AllSPFRouters or AllDRouters.
ToP   noToC   RFC2740 - Page 18
   o  The Next Header field of the immediately encapsulating IPv6 header
      must specify the OSPF protocol (89).

   o  Any encapsulating IP Authentication Headers (see [Ref19]) and the
      IP Encapsulating Security Payloads (see [Ref20]) must be processed
      and/or verified to ensure integrity and
      authentication/confidentiality of OSPF routing exchanges.

   o  Locally originated packets should not be passed on to OSPF.  That
      is, the source IPv6 address should be examined to make sure this
      is not a multicast packet that the router itself generated.

   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 interface.  If they do not, the
   packet should be discarded:

   o  The version number field must specify protocol version 3.

   o  The standard IPv6 16-bit one's complement checksum, covering the
      entire OSPF packet and prepended IPv6 pseudo-header, must be
      verified (see Section A.3.1).

   o  The Area ID found in the OSPF header must be verified.  If both of
      the following cases fail, the packet should be discarded.  The
      Area ID specified in the header must either:

      (1)   Match the Area ID of the receiving interface. In
            this case, unlike for IPv4, the IPv6 source
            address is not restricted to lie on the same IP
            subnet as the receiving interface. IPv6 OSPF runs
            per-link, instead of per-IP-subnet.

      (2)   Indicate the backbone.  In this case, the packet
            has been sent over a virtual link.  The receiving
            router must be an area border router, and the
            Router ID specified in the packet (the source
            router) must be the other end of a configured
            virtual link.  The receiving interface must also
            attach to the virtual link's configured Transit
            area.  If all of these checks succeed, the packet
            is accepted and is from now on associated with
            the virtual link (and the backbone area).

   o  The Instance ID specified in the OSPF header must match the
      receiving interface's Instance ID.
ToP   noToC   RFC2740 - Page 19
   o  Packets whose IP destination is AllDRouters should only be
      accepted if the state of the receiving interface is DR or Backup
      (see Section 9.1).

   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 Protocol.  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 the 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 remains
   unchanged from the IPv4 procedures documented in Sections 10.6, 10.7
   and 13.7 of [Ref1] respectively. The receiving of Hello Packets is
   documented in Section 3.2.2.1, and the receiving of Link State Update
   Packets is documented in Section 3.5.1.

3.2.2.1. Receiving Hello Packets
The receive processing of Hello Packets differs from Section 10.5 of [Ref1] in the following ways: o On all link types (e.g., broadcast, NBMA, point-to- point, etc), neighbors are identified solely by their OSPF Router ID. For all link types except virtual links, the Neighbor IP address is set to the IPv6 source address in the IPv6 header of the received OSPF Hello packet. o There is no longer a Network Mask field in the Hello Packet. o The neighbor's choice of Designated Router and Backup Designated Router is now encoded as an OSPF Router ID instead of an IP interface address.

3.3. The Routing table Structure

The routing table used by OSPF for IPv4 is defined in Section 11 of [Ref1]. For IPv6 there are analogous routing table entries: there are routing table entries for IPv6 address prefixes, and also for AS boundary routers. The latter routing table entries are only used to hold intermediate results during the routing table build process (see Section 3.8).
ToP   noToC   RFC2740 - Page 20
   Also, to hold the intermediate results during the shortest-path
   calculation for each area, there is a separate routing table for each
   area holding the following entries:

   o  An entry for each router in the area. Routers are identified by
      their OSPF router ID. These routing table entries hold the set of
      shortest paths through a given area to a given router, which in
      turn allows calculation of paths to the IPv6 prefixes advertised
      by that router in Intra-area-prefix-LSAs. If the router is also an
      area-border router, these entries are also used to calculate paths
      for inter-area address prefixes. If in addition the router is the
      other endpoint of a virtual link, the routing table entry
      describes the cost and viability of the virtual link.

   o  An entry for each transit link in the area. Transit links have
      associated network-LSAs. Both the transit link and the network-LSA
      are identified by a combination of the Designated Router's
      Interface ID on the link and the Designated Router's OSPF Router
      ID. These routing table entries allow later calculation of paths
      to IP prefixes advertised for the transit link in intra-area-
      prefix-LSAs.

   The fields in the IPv4 OSPF routing table (see Section 11 of [Ref1])
   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 Section
   A.4.9).

3.3.1. Routing table lookup

Routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4.


(page 20 continued on part 2)

Next Section