tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 5340

 
 
 

OSPF for IPv6

Part 2 of 4, p. 13 to 40
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 13 
4.  Implementation Details

   When going from IPv4 to IPv6, the basic OSPF mechanisms remain
   unchanged from those documented in [OSPFV2].  These mechanisms are
   briefly outlined in Section 4 of [OSPFV2].  Both IPv6 and IPv4 have a
   link-state database composed of LSAs and synchronized between
   adjacent routers.  Initial synchronization is performed through the
   Database Exchange process, which includes the exchange of Database
   Description, Link State Request, and Link State Update packets.
   Thereafter, database synchronization is maintained via flooding,
   utilizing Link State Update and Link State Acknowledgment packets.
   Both IPv6 and IPv4 use OSPF Hello packets to discover and maintain
   neighbor relationships, as well as to elect Designated Routers and
   Backup Designated Routers on broadcast and NBMA links.  The decision
   as to which neighbor relationships become adjacencies, and the basic
   ideas behind inter-area routing, importing external information in
   AS-external-LSAs, and the various routing calculations are also the
   same.

   In particular, the following IPv4 OSPF functionality described in
   [OSPFV2] remains completely unchanged for IPv6:

   o  Both IPv4 and IPv6 use OSPF packet types described in Section 4.3
      of [OSPFV2], namely: Hello, Database Description, Link State
      Request, Link State Update, and Link State Acknowledgment packets.
      While in some cases (e.g., Hello packets) their format has changed
      somewhat, the functions of the various packet types remain the
      same.

Top      Up      ToC       Page 14 
   o  The system requirements for an OSPF implementation remain
      unchanged, although OSPF for IPv6 requires an IPv6 protocol stack
      (from the network layer on down) since it runs directly over the
      IPv6 network layer.

   o  The discovery and maintenance of neighbor relationships, and the
      selection and establishment of adjacencies, remain the same.  This
      includes election of the Designated Router and Backup Designated
      Router on broadcast and NBMA links.  These mechanisms are
      described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2].

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

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

   o  The neighbor state machine, including the list of OSPF neighbor
      states and events, remains unchanged.  The neighbor state machine
      is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2].

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

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

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

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], with the following modifications:

   o  All LSAs with known LS type and AS flooding scope appear in the
      top-level data structure, instead of belonging to a specific area
      or link.  AS-external-LSAs are the only LSAs defined by this
      specification that have AS flooding scope.  LSAs with unknown LS

Top      Up      ToC       Page 15 
      type, U-bit set to 1 (flood even when unrecognized), and AS
      flooding scope also appear in the top-level data structure.

4.1.1.  The Area Data Structure

   The IPv6 area data structure contains all elements defined for IPv4
   areas in Section 6 of [OSPFV2].  In addition, all LSAs of known type
   that 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.

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]) as follows:

   Interface ID
      Every interface is assigned an Interface ID, which uniquely
      identifies the interface with the router.  For example, some
      implementations MAY be able to use the MIB-II IfIndex ([INTFMIB])
      as the Interface ID.  The Interface ID appears in Hello packets
      sent out the interface, the link-local-LSA originated by the
      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 a value other than 0 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) will then keep the two communities separate.

Top      Up      ToC       Page 16 
   List of LSAs with link-local scope
      All LSAs with link-local scope and that 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 on the interface is almost always a link-local address.  The
      one exception is for virtual links that 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 on the interface.  In
   addition, OSPF for IPv6 relies on the IP Authentication Header (see
   [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as
   described in [OSPFV3-AUTH] to ensure integrity and authentication/
   confidentiality of routing exchanges.  For this reason, AuType and
   Authentication key are not associated with IPv6 OSPF interfaces.

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

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]
   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 the Designated Router.

Top      Up      ToC       Page 17 
   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] respectively.  The decision as to which adjacencies to form
   also remains unchanged from the IPv4 logic documented in Section 10.4
   of [OSPFV2].

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.

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

Top      Up      ToC       Page 18 
   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 on which the packet is being sent.

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

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

   Selection of OSPF routing protocol packets' IPv6 source and
   destination addresses is performed identically to the IPv4 logic in
   Section 8.1 of [OSPFV2].  The IPv6 destination address is chosen from
   among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP
   address associated with the other end of the adjacency (which in
   IPv6, for all links except virtual links, is an IPv6 link-local
   address).

   The sending of Link State Request packets and Link State
   Acknowledgment packets remains unchanged from the IPv4 procedures
   documented in Sections 10.9 and 13.5 of [OSPFV2] respectively.
   Sending Hello packets is documented in Section 4.2.1.1, and the
   sending of Database Description packets in Section 4.2.1.2.  The
   sending of Link State Update packets is documented in Section 4.5.2.

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]):

   o  Before the Hello packet is sent on an interface, the interface's
      Interface ID MUST be copied into the Hello packet.

   o  The Hello packet no longer contains an IP network mask since OSPF
      for IPv6 runs per-link instead of per-subnet.

   o  The choice of Designated Router and Backup Designated Router is
      now indicated within Hellos by their Router IDs instead of by
      their IP interface addresses.  Advertising the Designated Router

Top      Up      ToC       Page 19 
      (or Backup Designated Router) as 0.0.0.0 indicates that the
      Designated Router (or Backup Designated Router) has not yet been
      chosen.

   o  The Options field within Hello packets has moved around, getting
      larger in the process.  More Options bits are now possible.  Those
      that MUST be set correctly in Hello packets are as follows.  The
      E-bit is set if and only if the interface attaches to a regular
      area, i.e., not a stub or NSSA area.  Similarly, the N-bit is set
      if and only if the interface attaches to an NSSA area (see
      [NSSA]).  Finally, the DC-bit is set if and only if the router
      wishes to suppress the sending of future Hellos over the interface
      (see [DEMAND]).  Unrecognized bits in the Hello packet's Options
      field should be cleared.

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

4.2.1.2.  Sending Database Description Packets

   The sending of Database Description packets differs from Section 10.8
   of [OSPFV2] in the following ways:

   o  The Options field within Database Description packets has moved
      around, getting larger in the process.  More Options bits are now
      possible.  Those that MUST be set correctly in Database
      Description packets are as follows.  The DC-bit is set if and only
      if the router wishes to suppress the sending of Hellos over the
      interface (see [DEMAND]).  Unrecognized bits in the Database
      Description packet's Options field should be cleared.

4.2.2.  Receiving Protocol Packets

   Whenever a router receives an OSPF protocol packet, it is marked with
   the interface on which it was received.  For routers that have
   virtual links configured, it may not be immediately obvious with
   which interface to associate the packet.  For example, consider the
   Router RT11 depicted in Figure 6 of [OSPFV2].  If RT11 receives an
   OSPF protocol packet on its interface to Network N8, it may want to
   associate the packet with the interface to Area 2, or with the
   virtual link to Router RT10 (which is part of the backbone).  In the
   following, we assume that the packet is initially associated with the
   non-virtual link.

   In order for the packet to be passed to OSPF for processing, the
   following tests must be performed on the encapsulating IPv6 headers:

Top      Up      ToC       Page 20 
   o  The packet's IP destination address MUST be one of the IPv6
      unicast addresses associated with the receiving interface (this
      includes link-local addresses), one of the IPv6 multicast
      addresses AllSPFRouters or AllDRouters, or an IPv6 global address
      (for virtual links).

   o  The Next Header field of the immediately encapsulating IPv6 header
      MUST specify the OSPF protocol (89).

   o  Any encapsulating IP Authentication Headers (see [IPAUTH]) and the
      IP Encapsulating Security Payloads (see [IPESP]) MUST be processed
      and/or verified to ensure integrity and authentication/
      confidentiality of OSPF routing exchanges.  This is described in
      [OSPFV3-AUTH].

   After processing the encapsulating IPv6 headers, the OSPF packet
   header is processed.  The fields specified in the header must match
   those configured for the receiving OSPFv3 interface.  If they do not,
   the packet SHOULD be discarded:

   o  The version number field MUST specify protocol version 3.

   o  The IPv6 Upper-Layer checksum (as described in Section 8.1 of
      [IPV6]), covering the entire OSPF packet and prepended IPv6
      pseudo-header, must be verified (see Appendix A.3.1).

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

      1.  Match one of the Area ID(s) and Interface Instance ID(s) for
          the receiving link.  Unlike IPv4, the IPv6 source address is
          not restricted to lie within the same IPv6 subnet as the
          receiving link.  IPv6 OSPF runs per-link instead of per-IP-
          subnet.

      2.  Match the backbone area and other criteria for a configured
          virtual link.  The receiving router must be an ABR (Area
          Border Router) and the Router ID specified in the packet (the
          source router) must be the other end of a configured virtual
          link.  Additionally, the receiving link must have an OSPFv3
          interface that attaches to the virtual link's configured
          transit area and the Instance ID must match the virtual link's
          Instance ID.  If all of these checks succeed, the packet is
          accepted and is associated with the virtual link (and the
          backbone area).

Top      Up      ToC       Page 21 
   o  Locally originated packets SHOULD NOT be processed by OSPF except
      for support of multiple interfaces attached to the same link as
      described in Section 4.9.  Locally originated packets have a
      source address equal to one of the router's local addresses.

   o  Packets whose IPv6 destination is AllDRouters should only be
      accepted if the state of the receiving OSPFv3 interface is DR or
      Backup (see Section 9.1 [OSPFV2]).

   After header processing, the packet is further processed according to
   its OSPF packet type.  OSPF packet types and functions are the same
   for both IPv4 and IPv6.

   If the packet type is Hello, it should then be further processed by
   the Hello packet processing as described in Section 4.2.2.1.  All
   other packet types are sent/received only on adjacencies.  This means
   that the packet must have been sent by one of the router's active
   neighbors.  The neighbor is identified by the Router ID appearing in
   the received packet's OSPF header.  Packets not matching any active
   neighbor are discarded.

   The receive processing of Database Description packets, Link State
   Request packets, and Link State Acknowledgment packets is almost
   identical to the IPv4 procedures documented in Sections 10.6, 10.7,
   and 13.7 of [OSPFV2] respectively with the exceptions noted below.

   o  LSAs with unknown LS types in Database Description packets that
      have an acceptable flooding scope are processed the same as LSAs
      with known LS types.  In OSPFv2 [OSPFV2], these would result in
      the adjacency being brought down with a SequenceMismatch event.

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

4.2.2.1.  Receiving Hello Packets

   The receive processing of Hello packets differs from Section 10.5 of
   [OSPFV2] in the following ways:

   o  On all link types (e.g., broadcast, NBMA, point-to-point, etc.),
      neighbors are identified solely by their OSPF Router ID.  For all
      link types except virtual links, the Neighbor IP address is set to
      the IPv6 source address in the IPv6 header of the received OSPF
      Hello packet.

   o  There is no longer a Network Mask field in the Hello packet.

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

4.3.  The Routing table Structure

   The routing table used by OSPF for IPv4 is defined in Section 11 of
   [OSPFV2].  For IPv6, there are analogous routing table entries: there
   are routing table entries for IPv6 address prefixes and also for AS
   boundary routers.  The latter routing table entries are only used to
   hold intermediate results during the routing table build process (see
   Section 4.8).

   Also, to hold the intermediate results during the shortest-path
   calculation for each area, there is a separate routing table for each
   area holding the following entries:

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

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

   The fields in the IPv4 OSPF routing table (see Section 11 of
   [OSPFV2]) remain valid for IPv6: optional capabilities (routers
   only), path type, cost, type 2 cost, link state origin, and for each
   of the equal cost paths to the destination, the next-hop and
   advertising routers.

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

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

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] and is not encoded
   within OSPF for IPv6's LSAs.

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

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], respectively.  However, the following fields
   have changed for IPv6:

   Options
      The Options field has been removed from the standard 20-byte LSA
      header and moved into the body of router-LSAs, network-LSAs,
      inter-area-router-LSAs, and link-LSAs.  The size of the Options
      field has increased from 8 to 24 bits, and some of the bit
      definitions have changed (see Appendix A.2).  Additionally, a
      separate PrefixOptions field, 8 bits in length, is attached to
      each prefix advertised within the body of an LSA.

   LS type
      The size of the LS type field has increased from 8 to 16 bits,
      with high-order bit encoding the handling of unknown types and the
      next two bits encoding flooding scope.  See Appendix A.4.2.1 for
      the current coding of the LS type field.

Top      Up      ToC       Page 24 
   Link State ID
      The Link State ID remains at 32 bits in length.  However, except
      for network-LSAs and link-LSAs, the 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.

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

   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) 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) 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 an unknown LS type, the
   U-bit set to 0, and/or link-local flooding scope are contained within
   the appropriate interface structure (see Section 4.1.2); this
   includes link-LSAs.

   To look up 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.

Top      Up      ToC       Page 25 
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].  The following events and/or actions are
   added for IPv6:

   o  The state or interface ID of one of the router's interfaces
      changes.  The router may need to (re)originate or flush its link-
      LSA and one or more router-LSAs and/or intra-area-prefix-LSAs.  If
      the router is the Designated Router, the router may also need to
      (re)originate and/or flush the network-LSA corresponding to the
      interface.

   o  The identity of a link's Designated Router changes.  The router
      may need to (re)originate or flush the link's network-LSA and one
      or more router-LSAs and/or intra-area-prefix-LSAs.

   o  A neighbor transitions to/from "Full" state.  The router may need
      to (re)originate or flush the link's network-LSA and one or more
      router-LSAs and/or intra-area-prefix-LSAs.

   o  The Interface ID of a neighbor changes.  This may cause a new
      instance of a router-LSA to be originated for the associated area.

   o  A new prefix is added to an attached link, or a prefix is deleted
      (both through configuration).  This causes the router to
      reoriginate its link-LSA for the link or, if it is the only router
      attached to the link, causes the router to reoriginate an intra-
      area-prefix-LSA.

   o  A new link-LSA is received, causing the link's collection of
      prefixes to change.  If the router is the Designated Router for
      the link, it originates a new intra-area-prefix-LSA.

   o  A new link-LSA is received, causing the logical OR of LSA options
      advertised by adjacent routers on the link to change.  If the
      router is the Designated Router for the link, it originates a new
      network-LSA.

   Detailed construction of the seven required IPv6 LSA types is
   supplied by the following subsections.  In order to display example
   LSAs, the network map in Figure 15 of [OSPFV2] has been reworked to
   show IPv6 addressing, resulting in Figure 1.  The OSPF cost of each

Top      Up      ToC       Page 26 
   interface is 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

Top      Up      ToC       Page 27 
               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

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

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

   Each of the router's interfaces to the area is then described by
   appending "link descriptions" to the router-LSA.  Each link
   description is 16 bytes long, consisting of five fields: (link) Type,

Top      Up      ToC       Page 28 
   Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID
   (see Appendix A.4.3).  Interfaces in the 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).  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 the 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).

   Point-to-Multipoint interfaces
      For each fully adjacent neighbor associated with the interface,
      add a separate Type 1 link description (point-to-point) with the
      Neighbor Interface ID field set to the Interface ID advertised by
      the neighbor in its Hello packets and the 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 the Designated Router of Network
   N3.

Top      Up      ToC       Page 29 
        ; 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.

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 which it is fully adjacent.

   The procedure for originating network-LSAs in IPv6 is the same as the
   IPv4 procedure documented in Section 12.4.2 of [OSPFV2], with the
   following exceptions:

   o  An IPv6 network-LSA's Link State ID is set to the Interface ID of
      the Designated Router on the link.

   o  IPv6 network-LSAs do not contain a Network Mask.  All addressing
      information formerly contained in the IPv4 network-LSA has now
      been consigned to intra-Area-Prefix-LSAs originated by the link's
      Designated Router.

Top      Up      ToC       Page 30 
   o  The Options field in the network-LSA is set to the logical OR of
      the Options fields contained within the link's associated link-
      LSAs corresponding to fully adjacent neighbors.  In this way, the
      network link exhibits a capability when at least one fully
      adjacent neighbor on the link requests that the capability be
      advertised.

   As an example, assuming that Router RT4 has been elected the
   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

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], with the following exceptions:

   o  The Link State ID of an inter-area-prefix-LSA has lost all of its
      addressing semantics and simply serves to distinguish multiple
      inter-area-prefix-LSAs that are originated by the same router.

   o  The prefix is described by the PrefixLength, PrefixOptions, and
      Address Prefix fields embedded within the LSA body.  Network Mask
      is no longer specified.

   o  The NU-bit in the PrefixOptions field should be clear.

Top      Up      ToC       Page 31 
   o  Link-local addresses MUST never be advertised in inter-area-
      prefix-LSAs.

   As an example, the following shows the inter-area-prefix-LSA that
   Router RT4 originates into the OSPF backbone area, condensing all of
   Area 1's prefixes into the single prefix 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

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 (i.e., an AS
   Boundary Router (ASBR)) that is external to the area yet internal to
   the Autonomous System.

   The procedure for originating inter-area-router-LSAs in IPv6 is the
   same as the IPv4 procedure documented in Section 12.4.3 of [OSPFV2],
   with the following exceptions:

   o  The Link State ID of an inter-area-router-LSA is no longer the
      destination router's OSPF Router ID and now simply serves to
      distinguish multiple inter-area-router-LSAs that are originated by
      the same router.  The destination router's Router ID is now found
      in the body of the LSA.

Top      Up      ToC       Page 32 
   o  The Options field in an inter-area-router-LSA should be set equal
      to the Options field contained in the destination router's own
      router-LSA.  The Options field thus describes the capabilities
      supported by the destination router.

   As an example, consider the OSPF Autonomous System depicted in Figure
   6 of [OSPFV2].  Router RT4 would originate into Area 1 the following
   inter-area-router-LSA for destination router RT7.

        ; inter-area-router-LSA for AS boundary router RT7
        ; originated by Router RT4 into Area 1

        LS age = 0                  ;newly (re)originated
        LS type = 0x2004            ;inter-area-router-LSA
        Advertising Router = 192.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

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], with the
   following exceptions:

   o  The Link State ID of an AS-external-LSA has lost all of its
      addressing semantics and simply serves to distinguish multiple AS-
      external-LSAs that are originated by the same router.

   o  The prefix is described by the PrefixLength, PrefixOptions, and
      Address Prefix fields embedded within the LSA body.  Network Mask
      is no longer specified.

   o  The NU-bit in the PrefixOptions field should be clear.

   o  Link-local addresses can never be advertised in AS-external-LSAs.

   o  The forwarding address is present in the AS-external-LSA if and
      only if the AS-external-LSA's bit F is set.

Top      Up      ToC       Page 33 
   o  The external route tag is present in the AS-external-LSA if and
      only if the AS-external-LSA's bit T is set.

   o  The capability for an AS-external-LSA to reference another LSA has
      been supported through the inclusion of the Referenced LS Type
      field and the optional Referenced Link State ID field (the latter
      present if and only if the Referenced LS Type is non-zero).  This
      capability is for future use; the Referenced LS Type should be set
      to 0, and received non-zero values for this field should be
      ignored until its use is defined.

   As an example, consider the OSPF Autonomous System depicted in Figure
   6 of [OSPFV2].  Assume that RT7 has learned its route to N12 via BGP
   and that it wishes to advertise a Type 2 metric into the AS.  Also
   assume that the IPv6 prefix for N12 is the value 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         ;LSA type/scope unique identifier
        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

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], with the following exceptions:

Top      Up      ToC       Page 34 
   o  The Link State ID of an NSSA-LSA has lost all of its addressing
      semantics and simply serves to distinguish multiple NSSA-LSAs that
      are originated by the same router in the same area.

   o  The prefix is described by the PrefixLength, PrefixOptions, and
      Address Prefix fields embedded within the LSA body.  Network Mask
      is no longer specified.

   o  The NU-bit in the PrefixOptions field should be clear.

   o  Link-local addresses can never be advertised in NSSA-LSAs.

   o  The forwarding address is present in the NSSA-LSA if and only if
      the NSSA-LSA's bit F is set.

   o  The external route tag is present in the NSSA-LSA if and only if
      the NSSA-LSA's bit T is set.

   o  The capability for an NSSA-LSA to reference another LSA has been
      supported through the inclusion of the Referenced LS Type field
      and the optional Referenced Link State ID field (the latter
      present if and only if the Referenced LS Type is non-zero).  This
      capability is for future use; the Referenced LS Type should be set
      to 0, and received non-zero values for this field should be
      ignored until its use is defined.

   An example of an NSSA-LSA would only differ from an AS-external-LSA
   in that the LS type would be 0x2007 rather than 0x4005.

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

Top      Up      ToC       Page 35 
   A link-LSA for a given Link L is built in the following fashion:

   o  The Link State ID is set to the router's Interface ID on Link L.

   o  The Router Priority of the router's interface to Link L is
      inserted into the link-LSA.

   o  The link-LSA's Options field is set to reflect the router's
      capabilities.  On multi-access links, the Designated Router will
      logically OR the link-LSA Options fields for all fully adjacent
      neighbors in Link L's network-LSA.

   o  The router inserts its link-local address on Link L into the link-
      LSA.  This information will be used when the other routers on Link
      L do their next-hop calculations (see Section 4.8.2).

   o  Each IPv6 address prefix that has been configured on Link L is
      added to the link-LSA by specifying values for the PrefixLength,
      PrefixOptions, and Address Prefix fields.

   After building a link-LSA for a given link, the router installs the
   link-LSA into the associated interface data structure and floods the
   link-LSA on the link.  All other routers on the link will receive the
   link-LSA, but they will not flood the link-LSA on other links.

   If LinkLSASuppression is configured for the interface and the
   interface type is not broadcast or NBMA, origination of the link-LSA
   may be suppressed.  This implies that other routers on the link will
   ascertain the router's next-hop address using a mechanism other than
   the link-LSA (see Section 4.8.2).  Refer to Appendix C.3 for a
   description of the LinkLSASuppression interface configuration
   parameter.

   As an example, consider the link-LSA that RT3 will build for N3 in
   Figure 1.  Suppose that the prefix 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.

Top      Up      ToC       Page 36 
        ; 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

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:

   o  In order to indicate that the prefixes are to be associated with
      the Link L, the fields Referenced LS Type, Referenced Link State
      ID, and Referenced Advertising Router are set to the corresponding
      fields in Link L's network-LSA (namely, LS type, Link State ID,
      and Advertising Router respectively).  This means that the
      Referenced LS Type is set to 0x2002, the Referenced Link State ID
      is set to the Designated Router's Interface ID on Link L, and the
      Referenced Advertising Router is set to the Designated Router's
      Router ID.

   o  Each link-LSA associated with Link L is examined (these are in the
      Designated Router's interface structure for Link L).  If the link-
      LSA's Advertising Router is fully adjacent to the Designated

Top      Up      ToC       Page 37 
      Router and the Link State ID matches the neighbor's interface ID,
      the list of prefixes in the link-LSA is copied into the intra-
      area-prefix-LSA that is being built.  Prefixes having the NU-bit
      and/or LA-bit set in their Options field SHOULD NOT be copied, nor
      should link-local addresses be copied.  Each prefix is described
      by the PrefixLength, PrefixOptions, and Address Prefix fields.
      Multiple prefixes having the same PrefixLength and Address Prefix
      are considered to be duplicates.  In this case, their
      PrefixOptions fields should be logically OR'ed together, and a
      single instance of the duplicate prefix should be included in the
      intra-area-prefix-LSA.  The Metric field for all prefixes is set
      to 0.

   o  The "# prefixes" field is set to the number of prefixes that the
      router has copied into the LSA.  If necessary, the list of
      prefixes can be spread across multiple intra-area-prefix-LSAs in
      order to keep the LSA size small.

   A router builds an intra-area-prefix-LSA to advertise prefixes for
   its attached stub links, looped-back interfaces, and hosts.  A Router
   RTX would build its intra-area-prefix-LSA in the following fashion:

   o  In order to indicate that the prefixes are to be associated with
      the Router RTX itself, RTX sets the Referenced LS Type to 0x2001,
      the Referenced Link State ID to 0, and the Referenced Advertising
      Router to RTX's own Router ID.

   o  Router RTX examines its list of interfaces to the area.  If the
      interface is in the state Down, its prefixes are not included.  If
      the interface has been reported in RTX's router-LSA as a Type 2
      link description (link to transit network), prefixes that will be
      included in the intra-area-prefix-LSA for the link are skipped.
      However, any prefixes that would normally have the LA-bit set
      SHOULD be advertised independent of whether or not the interface
      is advertised as a transit link.  If the interface type is point-
      to-multipoint or the interface is in the state Loopback, the
      global scope IPv6 addresses associated with the interface (if any)
      are copied into the intra-area-prefix-LSA with the PrefixOptions
      LA-bit set, the PrefixLength set to 128, and the metric set to 0.
      Otherwise, the list of global prefixes configured in RTX for the
      link are copied into the intra-area-prefix-LSA by specifying the
      PrefixLength, PrefixOptions, and Address Prefix fields.  The
      Metric field for each of these prefixes is set to the interface's
      output cost.

   o  RTX adds the IPv6 prefixes for any directly attached hosts
      belonging to the area (see Appendix C.7) to the intra-area-prefix-
      LSA.

Top      Up      ToC       Page 38 
   o  If RTX has one or more virtual links configured through the area,
      it includes one of its global scope IPv6 interface addresses in
      the LSA (if it hasn't already), setting the LA-bit in the
      PrefixOptions field, the PrefixLength to 128, and the Metric to 0.
      This information will be used later in the routing calculation so
      that the two ends of the virtual link can discover each other's
      IPv6 addresses.

   o  The "# prefixes" field is set to the number of prefixes that the
      router has copied into the LSA.  If necessary, the list of
      prefixes can be spread across multiple intra-area-prefix-LSAs in
      order to keep the LSA size small.

   For example, the intra-area-prefix-LSA originated by RT4 for Network
   N3 (assuming that RT4 is N3's Designated Router) and the intra-area-
   prefix-LSA originated into Area 1 by Router RT3 for its own prefixes
   are pictured below.

Top      Up      ToC       Page 39 
        ; 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           ;LSA type/scope unique identifier
        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         ;LSA type/scope unique identifier
        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 the 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 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

Top      Up      ToC       Page 40 
   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, the Referenced Advertising Router and Advertising Router would
   be different.

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, for example, OSPFv3 LSAs corresponding to
   information advertised in OSPFv2 using opaque LSAs [OPAQUE].  In
   general, the new information advertised in future LSAs should not be
   used unless the OSPFv3 router originating the LSA is reachable.
   However, depending on the application and the data advertised, this
   reachability validation MAY be done less frequently than every SPF
   calculation.

   To facilitate inter-area reachability validation, any OSPFv3 router
   originating AS scoped LSAs is considered an AS Boundary Router
   (ASBR).



(page 40 continued on part 3)

Next RFC Part