tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 5340

 Errata 
Proposed STD
Pages: 94
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: OSPF

OSPF for IPv6

Part 1 of 4, p. 1 to 13
None       Next RFC Part

Obsoletes:    2740
Updated by:    6845    6860    7503


Top       ToC       Page 1 
Network Working Group                                          R. Coltun
Request for Comments: 5340                          Acoustra Productions
Obsoletes: 2740                                              D. Ferguson
Category: Standards Track                               Juniper Networks
                                                                  J. Moy
                                                  Sycamore Networks, Inc
                                                          A. Lindem, Ed.
                                                        Redback Networks
                                                               July 2008


                             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.

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.

Page 2 
   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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Differences from OSPF for IPv4 . . . . . . . . . . . . . . . .  5
     2.1.  Protocol Processing Per-Link, Not Per-Subnet . . . . . . .  5
     2.2.  Removal of Addressing Semantics  . . . . . . . . . . . . .  5
     2.3.  Addition of Flooding Scope . . . . . . . . . . . . . . . .  6
     2.4.  Explicit Support for Multiple Instances per Link . . . . .  6
     2.5.  Use of Link-Local Addresses  . . . . . . . . . . . . . . .  7
     2.6.  Authentication Changes . . . . . . . . . . . . . . . . . .  7
     2.7.  Packet Format Changes  . . . . . . . . . . . . . . . . . .  8
     2.8.  LSA Format Changes . . . . . . . . . . . . . . . . . . . .  9
     2.9.  Handling Unknown LSA Types . . . . . . . . . . . . . . . . 10
     2.10. Stub/NSSA Area Support . . . . . . . . . . . . . . . . . . 11
     2.11. Identifying Neighbors by Router ID . . . . . . . . . . . . 11
   3.  Differences with RFC 2740  . . . . . . . . . . . . . . . . . . 11
     3.1.  Support for Multiple Interfaces on the Same Link . . . . . 11
     3.2.  Deprecation of MOSPF for IPv6  . . . . . . . . . . . . . . 12
     3.3.  NSSA Specification . . . . . . . . . . . . . . . . . . . . 12
     3.4.  Stub Area Unknown LSA Flooding Restriction Deprecated  . . 12
     3.5.  Link LSA Suppression . . . . . . . . . . . . . . . . . . . 12
     3.6.  LSA Options and Prefix Options Updates . . . . . . . . . . 13
     3.7.  IPv6 Site-Local Addresses  . . . . . . . . . . . . . . . . 13
   4.  Implementation Details . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Protocol Data Structures . . . . . . . . . . . . . . . . . 14
       4.1.1.  The Area Data Structure  . . . . . . . . . . . . . . . 15
       4.1.2.  The Interface Data Structure . . . . . . . . . . . . . 15
       4.1.3.  The Neighbor Data Structure  . . . . . . . . . . . . . 16
     4.2.  Protocol Packet Processing . . . . . . . . . . . . . . . . 17
       4.2.1.  Sending Protocol Packets . . . . . . . . . . . . . . . 17
         4.2.1.1.  Sending Hello Packets  . . . . . . . . . . . . . . 18
         4.2.1.2.  Sending Database Description Packets . . . . . . . 19
       4.2.2.  Receiving Protocol Packets . . . . . . . . . . . . . . 19
         4.2.2.1.  Receiving Hello Packets  . . . . . . . . . . . . . 21
     4.3.  The Routing table Structure  . . . . . . . . . . . . . . . 22
       4.3.1.  Routing Table Lookup . . . . . . . . . . . . . . . . . 23
     4.4.  Link State Advertisements  . . . . . . . . . . . . . . . . 23
       4.4.1.  The LSA Header . . . . . . . . . . . . . . . . . . . . 23
       4.4.2.  The Link-State Database  . . . . . . . . . . . . . . . 24
       4.4.3.  Originating LSAs . . . . . . . . . . . . . . . . . . . 25
         4.4.3.1.  LSA Options  . . . . . . . . . . . . . . . . . . . 27
         4.4.3.2.  Router-LSAs  . . . . . . . . . . . . . . . . . . . 27

Top      ToC       Page 3 
         4.4.3.3.  Network-LSAs . . . . . . . . . . . . . . . . . . . 29
         4.4.3.4.  Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . 30
         4.4.3.5.  Inter-Area-Router-LSAs . . . . . . . . . . . . . . 31
         4.4.3.6.  AS-External-LSAs . . . . . . . . . . . . . . . . . 32
         4.4.3.7.  NSSA-LSAs  . . . . . . . . . . . . . . . . . . . . 33
         4.4.3.8.  Link-LSAs  . . . . . . . . . . . . . . . . . . . . 34
         4.4.3.9.  Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . 36
       4.4.4.  Future LSA Validation  . . . . . . . . . . . . . . . . 40
     4.5.  Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 40
       4.5.1.  Receiving Link State Update Packets  . . . . . . . . . 40
       4.5.2.  Sending Link State Update Packets  . . . . . . . . . . 41
       4.5.3.  Installing LSAs in the Database  . . . . . . . . . . . 43
     4.6.  Definition of Self-Originated LSAs . . . . . . . . . . . . 43
     4.7.  Virtual Links  . . . . . . . . . . . . . . . . . . . . . . 44
     4.8.  Routing Table Calculation  . . . . . . . . . . . . . . . . 44
       4.8.1.  Calculating the Shortest-Path Tree for an Area . . . . 45
       4.8.2.  The Next-Hop Calculation . . . . . . . . . . . . . . . 44
       4.8.3.  Calculating the Inter-Area Routes  . . . . . . . . . . 47
       4.8.4.  Examining Transit Areas' Summary-LSAs  . . . . . . . . 48
       4.8.5.  Calculating AS External and NSSA Routes  . . . . . . . 48
     4.9.  Multiple Interfaces to a Single Link . . . . . . . . . . . 48
       4.9.1.  Standby Interface State  . . . . . . . . . . . . . . . 50
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 52
   6.  Manageability Considerations . . . . . . . . . . . . . . . . . 52
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 52
     7.1.  MOSPF for OSPFv3 Deprecation IANA Considerations . . . . . 53
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 53
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 55
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 56
   Appendix A.  OSPF Data Formats . . . . . . . . . . . . . . . . . . 57
     A.1.  Encapsulation of OSPF Packets  . . . . . . . . . . . . . . 57
     A.2.  The Options Field  . . . . . . . . . . . . . . . . . . . . 58
     A.3.  OSPF Packet Formats  . . . . . . . . . . . . . . . . . . . 60
       A.3.1.  The OSPF Packet Header . . . . . . . . . . . . . . . . 60
       A.3.2.  The Hello Packet . . . . . . . . . . . . . . . . . . . 62
       A.3.3.  The Database Description Packet  . . . . . . . . . . . 63
       A.3.4.  The Link State Request Packet  . . . . . . . . . . . . 65
       A.3.5.  The Link State Update Packet . . . . . . . . . . . . . 66
       A.3.6.  The Link State Acknowledgment Packet . . . . . . . . . 67
     A.4.  LSA Formats  . . . . . . . . . . . . . . . . . . . . . . . 68
       A.4.1.  IPv6 Prefix Representation . . . . . . . . . . . . . . 69
         A.4.1.1.  Prefix Options . . . . . . . . . . . . . . . . . . 69
       A.4.2.  The LSA Header . . . . . . . . . . . . . . . . . . . . 70
         A.4.2.1.  LSA Type . . . . . . . . . . . . . . . . . . . . . 72
       A.4.3.  Router-LSAs  . . . . . . . . . . . . . . . . . . . . . 73
       A.4.4.  Network-LSAs . . . . . . . . . . . . . . . . . . . . . 76
       A.4.5.  Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 77

Top      ToC       Page 4 
       A.4.6.  Inter-Area-Router-LSAs . . . . . . . . . . . . . . . . 78
       A.4.7.  AS-External-LSAs . . . . . . . . . . . . . . . . . . . 79
       A.4.8.  NSSA-LSAs  . . . . . . . . . . . . . . . . . . . . . . 82
       A.4.9.  Link-LSAs  . . . . . . . . . . . . . . . . . . . . . . 82
       A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 84
   Appendix B.  Architectural Constants . . . . . . . . . . . . . . . 86
   Appendix C.  Configurable Constants  . . . . . . . . . . . . . . . 86
     C.1.  Global Parameters  . . . . . . . . . . . . . . . . . . . . 86
     C.2.  Area Parameters  . . . . . . . . . . . . . . . . . . . . . 87
     C.3.  Router Interface Parameters  . . . . . . . . . . . . . . . 88
     C.4.  Virtual Link Parameters  . . . . . . . . . . . . . . . . . 90
     C.5.  NBMA Network Parameters  . . . . . . . . . . . . . . . . . 91
     C.6.  Point-to-Multipoint Network Parameters . . . . . . . . . . 92
     C.7.  Host Route Parameters  . . . . . . . . . . . . . . . . . . 92

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.

1.1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-KEYWORDS].

1.2.  Terminology

   This document attempts to use terms from both the OSPF for IPv4
   specification ([OSPFV2]) and the IPv6 protocol specifications
   ([IPV6]).  This has produced a mixed result.  Most of the terms used
   both by OSPF and IPv6 have roughly the same meaning (e.g.,

Top      ToC       Page 5 
   interfaces).  However, there are a few conflicts.  IPv6 uses "link"
   similarly to IPv4 OSPF's "subnet" or "network".  In this case, we
   have chosen to use IPv6's "link" terminology.  "Link" replaces OSPF's
   "subnet" and "network" in most places in this document, although
   OSPF's network-LSA remains unchanged (and possibly unfortunately, a
   new link-LSA has also been created).

   The names of some of the OSPF LSAs have also changed.  See
   Section 2.8 for details.

   In the context of this document, an OSPF instance is a separate
   protocol instance complete with its own protocol data structures
   (e.g., areas, interfaces, neighbors), link-state database, protocol
   state machines, and protocol processing (e.g., SPF calculation).

2.  Differences from OSPF for IPv4

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

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

2.1.  Protocol Processing Per-Link, Not Per-Subnet

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

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

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

2.2.  Removal of Addressing Semantics

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

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

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

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

   o  Neighboring routers are now always identified by Router ID.
      Previously, they had been identified by 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:

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

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

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

2.4.  Explicit Support for Multiple Instances per Link

   OSPF now supports the ability to run multiple OSPF protocol instances
   on a single link.  For example, this may be required on a NAP segment
   shared between several providers.  Providers may be supporting
   separate OSPF routing domains that wish to remain separate even
   though they have one or more physical network segments (i.e., links)
   in common.  In OSPF for IPv4, this was supported in a haphazard
   fashion using the authentication fields in the OSPF for IPv4 header.

Top      ToC       Page 7 
   Another use for running multiple OSPF instances is if you want, for
   one reason or another, to have a single link belong to two or more
   OSPF areas.

   Support for multiple protocol instances on a link is accomplished via
   an "Instance ID" contained in the OSPF packet header and OSPF
   interface data structures.  Instance ID solely affects the reception
   of OSPF packets and applies to normal OSPF interfaces and virtual
   links.

2.5.  Use of Link-Local Addresses

   IPv6 link-local addresses are for use on a single link, for purposes
   of neighbor discovery, auto-configuration, etc.  IPv6 routers do not
   forward IPv6 datagrams having link-local source addresses [IP6ADDR].
   Link-local unicast addresses are assigned from the IPv6 address range
   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.

Top      ToC       Page 8 
   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:

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

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

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

   o  The Hello packet now contains no address information at all.
      Rather, it now includes an Interface ID 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.

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

   o  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).

Top      ToC       Page 9 
2.8.  LSA Format Changes

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

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

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

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

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

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

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

   o  A new LSA called the link-LSA has been introduced.  Link-LSAs have
      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.

   o  In IPv4, the router-LSA carries a router's IPv4 interface
      addresses, the IPv4 equivalent of link-local addresses.  These are
      only used when calculating next hops during the OSPF routing
      calculation (see Section 16.1.1 of [OSPFV2]), so they do not need
      to be flooded past the local link.  Hence, using link-LSAs to
      distribute these addresses is more efficient.  Note that link-
      local addresses cannot be learned through the reception of Hellos

Top      ToC       Page 10 
      in all cases.  On NBMA links, next-hop routers do not necessarily
      exchange Hellos.  Rather, these routers learn of each other's
      existence by way of the Designated Router (DR).

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

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

   o  The Link State ID in inter-area-prefix-LSAs, inter-area-router-
      LSAs, NSSA-LSAs, and AS-external-LSAs has lost its addressing
      semantics and now serves solely to identify individual pieces of
      the Link State Database.  All addresses or Router IDs that were
      formerly expressed by the Link State ID are now carried in the LSA
      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 4.4.3.9 for
      details.

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

2.9.  Handling Unknown LSA Types

   Handling of unknown LSA types has been made more flexible so that,
   based on 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).

Top      ToC       Page 11 
   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.

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

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 specifies the additions and clarifications necessary for
   implementation.  They are fully compatible with RFC 2740.

Top      ToC       Page 12 
3.2.  Deprecation of MOSPF for IPv6

   This protocol feature was only partially specified in RFC 2740.  The
   level of specification was insufficient to implement the feature.
   There are no known implementations.  Multicast Extensions to OSPF
   (MOSPF) support and its attendant protocol fields have been
   deprecated from OSPFv3.  Refer to Section 4.4.3.2, Section 4.4.3.4,
   Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1,
   Appendix A.4.3, Appendix A.4.1.1, and Section 7.1.

3.3.  NSSA Specification

   This protocol feature was only partially specified in RFC 2740.  The
   level of specification was insufficient to implement the function.
   This document includes an NSSA specification unique to OSPFv3.  This
   specification coupled with [NSSA] provide sufficient specification
   for implementation.  Refer to Section 4.8.5, Appendix A.4.3,
   Appendix A.4.8, and [NSSA].

3.4.  Stub Area Unknown LSA Flooding Restriction Deprecated

   In RFC 2740 [OSPFV3], 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.

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

Top      ToC       Page 13 
   may be suppressed.  The LinkLSASuppression interface configuration
   parameter is described in Appendix C.3.  Section 4.8.2 and
   Section 4.4.3.8 were updated to reflect the parameter's usage.

3.6.  LSA Options and Prefix Options Updates

   The LSA Options and Prefix Options fields have been updated to
   reflect recent protocol 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 and Appendix A.4.1.1.

3.7.  IPv6 Site-Local Addresses

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



(page 13 continued on part 2)

Next RFC Part