tech-invite   World Map     

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

RFC 5340

 
 
 

OSPF for IPv6

Part 3 of 4, p. 40 to 68
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 40 
4.5.  Flooding

   Most of the flooding algorithm remains unchanged from the IPv4
   flooding mechanisms described in Section 13 of [OSPFV2].  In
   particular, the protocol processes for determining which LSA instance
   is newer (Section 13.1 of [OSPFV2]), responding to updates of self-
   originated LSAs (Section 13.4 of [OSPFV2]), sending Link State
   Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting
   LSAs (Section 13.6 of [OSPFV2]), and receiving Link State
   Acknowledgment packets (Section 13.7 of [OSPFV2]), are exactly the
   same for IPv6 and IPv4.

   However, the addition of flooding scope and unknown LSA type handling
   (see Appendix A.4.2.1) has caused some changes in the OSPF flooding
   algorithm: the reception of Link State Updates (Section 13 in
   [OSPFV2]) and the sending of Link State Updates (Section 13.3 of
   [OSPFV2]) must take into account the LSA's scope and U-bit setting.
   Also, installation of LSAs into the OSPF database (Section 13.2 of
   [OSPFV2]) causes different events in IPv6, due to the reorganization
   of LSA types and the IPv6 LSA contents.  These changes are described
   in detail below.

4.5.1.  Receiving Link State Update Packets

   The encoding of flooding scope in the LS type and the need to process
   unknown LS types cause modifications to the processing of received
   Link State Update packets.  As in IPv4, each LSA in a received Link

Top      Up      ToC       Page 41 
   State Update packet is examined.  In IPv4, eight steps are executed
   for each LSA, as described in Section 13 of [OSPFV2].  For IPv6, all
   the steps are the same, except that Steps 2 and 3 are modified as
   follows:

      (2)   Examine the LSA's LS type.  Discard the LSA and get
            the next one from the Link State Update packet if the
            interface area has been configured as a stub or
            NSSA area and the LS type indicates "AS flooding scope".

            This generalizes the IPv4 behavior where AS-external-LSAs
            and AS-scoped opaque LSAs [OPAQUE] are not flooded
            throughout stub or NSSA areas.

      (3)   Else if the flooding scope in the LSA's LS type is set to
            "reserved", discard the LSA and get the next one from
            the Link State Update packet.

   Steps 5b (sending Link State Update packets) and 5d (installing LSAs
   in the link-state database) in Section 13 of [OSPFV2] are also
   somewhat different for IPv6, as described in Sections 4.5.2 and 4.5.3
   below.

4.5.2.  Sending Link State Update Packets

   The sending of Link State Update packets is described in Section 13.3
   of [OSPFV2].  For IPv4 and IPv6, the steps for sending a Link State
   Update packet are the same (steps 1 through 5 of Section 13.3 in
   [OSPFV2]).  However, the list of eligible interfaces on which to
   flood the LSA is different.  For IPv6, the eligible interfaces are
   selected based on the following factors:

   o  The LSA's flooding scope.

   o  For LSAs with area or link-local flooding scope, the particular
      area or interface with which the LSA is associated.

   o  Whether the LSA has a recognized LS type.

   o  The setting of the U-bit in the LS type.  If the U-bit is set to
      0, unrecognized LS types are treated as having link-local scope.
      If set to 1, unrecognized LS types are stored and flooded as if
      they were recognized.

Top      Up      ToC       Page 42 
   Choosing the set of eligible interfaces then breaks into the
   following cases:

   Case 1
      The LSA's LS type is recognized.  In this case, the set of
      eligible interfaces is set depending on the flooding scope encoded
      in the LS type.  If the flooding scope is "AS flooding scope", the
      eligible interfaces are all router interfaces excepting virtual
      links.  In addition, AS-external-LSAs are not flooded on
      interfaces connecting to stub or NSSA areas.  If the flooding
      scope is "area flooding scope", the eligible interfaces are those
      interfaces connecting to the LSA's associated area.  If the
      flooding scope is "link-local flooding scope", then there is a
      single eligible interface, the one connecting to the LSA's
      associated link (which is also the interface on which the LSA was
      received in a Link State Update packet).

   Case 2
      The LS type is unrecognized and the U-bit in the LS type is set to
      0 (treat the LSA as if it had link-local flooding scope).  In this
      case, there is a single eligible interface, namely, the interface
      on which the LSA was received.

   Case 3
      The LS type is unrecognized, and the U-bit in the LS type is set
      to 1 (store and flood the LSA as if the type is understood).  In
      this case, select the eligible interfaces based on the encoded
      flooding scope the same as in Case 1 above.

   A further decision must sometimes be made before adding an LSA to a
   given neighbor's link-state retransmission list (Step 1d in Section
   13.3 of [OSPFV2]).  If the LS type is recognized by the router but
   not by the neighbor (as can be determined by examining the Options
   field that the neighbor advertised in its Database Description
   packet) and the LSA's U-bit is set to 0, then the LSA should be added
   to the neighbor's link-state retransmission list if and only if that
   neighbor is the Designated Router or Backup Designated Router for the
   attached link.  The LS types described in detail by this document,
   namely, router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter-
   area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs
   (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra-
   Area-Prefix-LSAs (0x2009), are assumed to be understood by all
   routers.  However, all LS types MAY not be understood by all routers.
   For example, a new LSA type with its U-bit set to 0 MAY only be
   understood by a subset of routers.  This new LS type should only be
   flooded to an OSPF neighbor that understands the LS type or when the
   neighbor is the Designated Router or Backup Designated Router for the
   attached link.

Top      Up      ToC       Page 43 
   The previous paragraph solves a problem for IPv4 OSPF extensions,
   which require that the Designated Router support the extension in
   order to have the new LSA types flooded across broadcast and NBMA
   networks.

4.5.3.  Installing LSAs in the Database

   There are three separate places to store LSAs, depending on their
   flooding scope.  LSAs with AS flooding scope are stored in the global
   OSPF data structure (see Section 4.1) as long as their LS type is
   known or their U-bit is 1.  LSAs with area flooding scope are stored
   in the appropriate area data structure (see Section 4.1.1) as long as
   their LS type is known or their U-bit is 1.  LSAs with link-local
   flooding scope, and those LSAs with unknown LS type and U-bit set to
   0 (treat the LSA as if it had link-local flooding scope), are stored
   in the appropriate interface data structure.

   When storing the LSA into the link-state database, a check must be
   made to see whether the LSA's contents have changed.  Changes in
   contents are indicated exactly as in Section 13.2 of [OSPFV2].  When
   an LSA's contents have been changed, the following parts of the
   routing table must be recalculated, based on the LSA's LS type:

   Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs
      The entire routing table is recalculated, starting with the
      shortest-path calculation for each area (see Section 4.8).

   Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs
      The best route to the destination described by the LSA must be
      recalculated (see Section 16.5 in [OSPFV2]).  If this destination
      is an AS boundary router, it may also be necessary to re-examine
      all the AS-external-LSAs.

   AS-external-LSAs and NSSA-LSAs
      The best route to the destination described by the AS-external-LSA
      or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and
      Section 2.0 in [NSSA]).

   As in IPv4, any old instance of the LSA must be removed from the
   database when the new LSA is installed.  This old instance must also
   be removed from all neighbors' link-state retransmission lists.

4.6.  Definition of Self-Originated LSAs

   In IPv6, the definition of a self-originated LSA has been simplified
   from the IPv4 definition appearing in Sections 13.4 and 14.1 of
   [OSPFV2].  For IPv6, self-originated LSAs are those LSAs whose
   Advertising Router is equal to the router's own Router ID.

Top      Up      ToC       Page 44 
4.7.  Virtual Links

   OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2].
   Virtual links are the same in IPv6, with the following exceptions:

   o  LSAs having AS flooding scope are never flooded over virtual
      adjacencies, nor are LSAs with AS flooding scope summarized over
      virtual adjacencies during the database exchange process.  This is
      a generalization of the IPv4 treatment of AS-external-LSAs.

   o  The IPv6 interface address of a virtual link MUST be an IPv6
      address having global scope, instead of the link-local addresses
      used by other interface types.  This address is used as the IPv6
      source for OSPF protocol packets sent over the virtual link.
      Hence, a link-LSA SHOULD NOT be originated for a virtual link
      since the virtual link has no link-local address or associated
      prefixes.

   o  Likewise, the virtual neighbor's IPv6 address is an IPv6 address
      with global scope.  To enable the discovery of a virtual
      neighbor's IPv6 address during the routing calculation, the
      neighbor advertises its virtual link's IPv6 interface address in
      an intra-area-prefix-LSA originated for the virtual link's transit
      area (see Section 4.4.3.9 and Section 4.8.1).

   o  Like all other IPv6 OSPF interfaces, virtual links are assigned
      unique (within the router) Interface IDs.  These are advertised in
      Hellos sent over the virtual link and in the router's router-LSAs.

4.8.  Routing Table Calculation

   The IPv6 OSPF routing calculation proceeds along the same lines as
   the IPv4 OSPF routing calculation, following the five steps specified
   by Section 16 of [OSPFV2].  High-level differences between the IPv6
   and IPv4 calculations include:

   o  Prefix information has been removed from router-LSAs and network-
      LSAs and is now advertised in intra-area-prefix-LSAs.  Whenever
      [OSPFV2] specifies that stub networks within router-LSAs be
      examined, IPv6 will instead examine prefixes within intra-area-
      prefix-LSAs.

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

Top      Up      ToC       Page 45 
   o  Addressing information is no longer encoded in Link State IDs and
      is now only found within the body of LSAs.

   o  In IPv6, a router can originate multiple router-LSAs,
      distinguished by Link State ID, within a single area.  These
      router-LSAs MUST be treated as a single aggregate by the area's
      shortest-path calculation (see Section 4.8.1).

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

   Events generated as a result of routing table changes (Section 16.7
   of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of
   [OSPFV2]) are identical for both IPv4 and IPv6.

4.8.1.  Calculating the Shortest-Path Tree for an Area

   The IPv4 shortest-path calculation is contained in Section 16.1 of
   [OSPFV2].  The graph used by the shortest-path tree calculation is
   identical for both IPv4 and IPv6.  The graph's vertices are routers
   and transit links, represented by router-LSAs and network-LSAs
   respectively.  A router is identified by its OSPF Router ID, while a
   transit link is identified by its Designated Router's Interface ID
   and OSPF Router ID.  Both routers and transit links have associated
   routing table entries within the area (see Section 4.3).

   Section 16.1 of [OSPFV2] splits up the shortest-path calculations
   into two stages.  First, the Dijkstra calculation is performed, and
   then the stub links are added onto the tree as leaves.  The IPv6
   calculation maintains this split.

   The Dijkstra calculation for IPv6 is identical to that specified for
   IPv4, with the following exceptions (referencing the steps from the
   Dijkstra calculation as described in Section 16.1 of [OSPFV2]):

   o  The Vertex ID for a router is the OSPF Router ID.  The Vertex ID
      for a transit network is a combination of the Interface ID and
      OSPF Router ID of the network's Designated Router.

   o  In Step 2, when a router Vertex V has just been added to the
      shortest-path tree, there may be multiple LSAs associated with the
      router.  All router-LSAs with the Advertising Router set to V's
      OSPF Router ID MUST be processed as an aggregate, treating them as
      fragments of a single large router-LSA.  The Options field and the

Top      Up      ToC       Page 46 
      router type bits (bits Nt, V, E, and B) should always be taken
      from the router-LSA with the smallest Link State ID.

   o  Step 2a is not needed in IPv6, as there are no longer stub network
      links in router-LSAs.

   o  In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is
      not set in the LSA options, the transit link W is ignored and V's
      next link is examined.

   o  In Step 2b, if W is a router, there may again be multiple LSAs
      associated with the router.  All router-LSAs with the Advertising
      Router set to W's OSPF Router ID MUST be processed as an
      aggregate, treating them as fragments of a single large router-
      LSA.

   o  In Step 4, there are now per-area routing table entries for each
      of an area's routers rather than just the area border routers.
      These entries subsume all the functionality of IPv4's area border
      router routing table entries, including the maintenance of virtual
      links.  When the router added to the area routing table in this
      step is the other end of a virtual link, the virtual neighbor's IP
      address is set as follows: The collection of intra-area-prefix-
      LSAs originated by the virtual neighbor is examined, with the
      virtual neighbor's IP address being set to the first prefix
      encountered with the LA-bit set.

   o  Routing table entries for transit networks, which are no longer
      associated with IP networks, are also calculated in Step 4 and
      added to the per-area routing table.

   The next stage of the shortest-path calculation proceeds similarly to
   the two steps of the second stage of Section 16.1 in [OSPFV2].
   However, instead of examining the stub links within router-LSAs, the
   list of the area's intra-area-prefix-LSAs is examined.  A prefix
   advertisement whose NU-bit is set SHOULD NOT be included in the
   routing calculation.  The cost of any advertised prefix is the sum of
   the prefix's advertised metric plus the cost to the transit vertex
   (either router or transit network) identified by intra-area-prefix-
   LSA's Referenced LS Type, Referenced Link State ID, and Referenced
   Advertising Router fields.  This latter cost is stored in the transit
   vertex's routing table entry for the area.

   This specification does not require that the above algorithm be used
   to calculate the intra-area shortest-path tree.  However, if another
   algorithm or optimization is used, an identical shortest-path tree
   must be produced.  It is also important that any alternate algorithm
   or optimization maintain the requirement that transit vertices must

Top      Up      ToC       Page 47 
   be bidirectional for inclusion in the tree.  Alternate algorithms and
   optimizations are beyond the scope of this specification.

4.8.2.  The Next-Hop Calculation

   In IPv6, the calculation of the next-hop's IPv6 address (which will
   be a link-local address) proceeds along the same lines as the IPv4
   next-hop calculation (see Section 16.1.1 of [OSPFV2]).  However,
   there are some differences.  When calculating the next-hop IPv6
   address for a router (call it Router X) that shares a link with the
   calculating router, the calculating router assigns the next-hop IPv6
   address to be the link-local interface address contained in Router
   X's link-LSA (see Appendix A.4.9) for the link.  This procedure is
   necessary for some link types, for example NBMA, where the two
   routers need not be neighbors and might not be exchanging OSPF Hello
   packets.  For other link types, the next-hop address may be
   determined via the IPv6 source address in the neighbor's Hello
   packet.

   Additionally, when calculating routes for the area's intra-area-
   prefix-LSAs, the parent vertex can be either a router-LSA or network-
   LSA.  This is in contrast to the second stage of the OSPFv2 intra-
   area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always
   a router-LSA.  In the case where the intra-area-prefix-LSA's
   referenced LSA is a directly connected network-LSA, the prefixes are
   also considered to be directly connected.  In this case, the next hop
   is solely the outgoing link and no IPv6 next-hop address is selected.

4.8.3.  Calculating the Inter-Area Routes

   Calculation of inter-area routes for IPv6 proceeds along the same
   lines as the IPv4 calculation in Section 16.2 of [OSPFV2], with the
   following modifications:

   o  The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have
      been changed to inter-area-prefix-LSAs and inter-area-router-LSAs
      respectively.

   o  The Link State ID of the above LSA types no longer encodes the
      network or router described by the LSA.  Instead, an address
      prefix is contained in the body of an inter-area-prefix-LSA and an
      advertised AS boundary router's OSPF Router ID is carried in the
      body of an inter-area-router-LSA.

   o  Prefixes having the NU-bit set in their PrefixOptions field should
      be ignored by the inter-area route calculation.

Top      Up      ToC       Page 48 
   When a single inter-area-prefix-LSA or inter-area-router-LSA has
   changed, the incremental calculations outlined in Section 16.5 of
   [OSPFV2] can be performed instead of recalculating the entire routing
   table.

4.8.4.  Examining Transit Areas' Summary-LSAs

   Examination of transit areas' summary-LSAs in IPv6 proceeds along the
   same lines as the IPv4 calculation in Section 16.3 of [OSPFV2],
   modified in the same way as the IPv6 inter-area route calculation in
   Section 4.8.3.

4.8.5.  Calculating AS External and NSSA Routes

   The IPv6 AS external route calculation proceeds along the same lines
   as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5
   of [NSSA], with the following exceptions:

   o  The Link State ID of the AS-external-LSA and NSSA-LSA types no
      longer encodes the network described by the LSA.  Instead, an
      address prefix is contained in the body of the LSA.

   o  The default route in AS-external-LSAs or NSSA-LSAs is advertised
      by a zero-length prefix.

   o  Instead of comparing the AS-external-LSA's or NSSA-LSA's
      Forwarding Address field to 0.0.0.0 to see whether a forwarding
      address has been used, the bit F in the respective LSA is
      examined.  A forwarding address is in use if and only if bit F is
      set.

   o  Prefixes having the NU-bit set in their PrefixOptions field should
      be ignored by the inter-area route calculation.

   o  AS Boundary Router (ASBR) and forwarding address selection will
      proceed the same as if RFC1583Compatibility is disabled.
      Furthermore, RFC1583Compatibility is not an OSPF for IPv6
      configuration parameter.  Refer to Appendix C.1.

   When a single AS-external-LSA or NSSA-LSA has changed, the
   incremental calculations outlined in Section 16.6 of [OSPFV2] can be
   performed instead of recalculating the entire routing table.

4.9.  Multiple Interfaces to a Single Link

   In OSPF for IPv6, a router may have multiple interfaces to a single
   link associated with the same OSPF instance and area.  All interfaces

Top      Up      ToC       Page 49 
   will be used for the reception and transmission of data traffic while
   only a single interface sends and receives OSPF control traffic.  In
   more detail:

   o  Each of the multiple interfaces is assigned a different Interface
      ID.  A router will automatically detect that multiple interfaces
      are attached to the same link when a Hello packet is received with
      one of the router's link-local addresses as the source address and
      an Interface ID other than the Interface ID of the receiving
      interface.

   o  Each of the multiple interfaces MUST be configured with the same
      Interface Instance ID to be considered on the same link.  If an
      interface has multiple Instance IDs, it will be grouped with other
      interfaces based on matching Instance IDs.  Each Instance ID will
      be treated uniquely with respect to groupings of multiple
      interfaces on the same link.  For example, if interface A is
      configured with Instance IDs 1 and 35, and interface B is
      configured with Instance ID 35, interface B may be the Active
      Interface for Instance ID 35 but interface A will be active for
      Instance ID 1.

   o  The router will ignore OSPF packets other than Hello packets on
      all but one of the interfaces attached to the link.  It will only
      send its OSPF control packets (including Hello packets) on a
      single interface.  This interface is designated the Active
      Interface and other interfaces attached to the same link will be
      designated Standby Interfaces.  The choice of the Active Interface
      is implementation dependent.  For example, the interface with the
      highest Interface ID could be chosen.  If the router is elected
      Designated Router, it will be the Active Interface's Interface ID
      that will be used as the network-LSA's Link State ID.

   o  All of the interfaces to the link (Active and Standby) will appear
      in the router-LSA.  In addition, a link-LSA will be generated for
      each of the interfaces.  In this way, all interfaces will be
      included in OSPF's routing calculations.

   o  Any link-local scope LSAs that are originated for a Standby
      Interface will be flooded over the Active Interface.
      If a Standby Interface goes down, then the link-local scope LSAs
      originated for the Standby Interfaces MUST be flushed on the
      Active Interface.

   o  Prefixes on Standby Interfaces will be processed the same way as
      prefixes on the Active Interface.  For example, if the router is
      the DR for the link, the Active Interface's prefixes are included

Top      Up      ToC       Page 50 
      in an intra-area-prefix-LSA which is associated with the Active
      Interface's network-LSA; prefixes from Standby Interfaces on the
      link will also be included in that intra-area-prefix LSA.
      Similarly, if the link is a stub link, then the prefixes for the
      Active and Standby Interfaces will all be included in the same
      intra-area-prefix-LSA that is associated with the router-LSA.

   o  If the Active Interface fails, a new Active Interface will have to
      take over.  The new Active Interface SHOULD form all new neighbor
      adjacencies with routers on the link.  This failure can be
      detected when the router's other interfaces to the Active
      Interface's link cease to hear the router's Hellos or through
      internal mechanisms, e.g., monitoring the Active Interface's
      status.

   o  If the network becomes partitioned with different local interfaces
      attaching to different network partitions, multiple interfaces
      will become Active Interfaces and function independently.

   o  During the SPF calculation when a network-LSA for a network that
      is directly connected to the root vertex is being examined, all of
      the multiple interfaces to the link of adjacent router-LSAs must
      be used in the next-hop calculation.
      This can be accomplished during the back link check (see Section
      16.1, Step 2 (B), in [OSPFV2]) by examining each link of the
      router-LSA and making a list of the links that point to the
      network-LSA.  The Interface IDs for links in this list are then
      used to find the corresponding link-LSAs and the link-local
      addresses used as next hops when installing equal-cost paths in
      the routing table.

   o  The interface state machine is modified to add the state Standby.
      See Section 4.9.1 for a description of the Standby state.

4.9.1.  Standby Interface State

   In this state, the interface is one of multiple interfaces to a link
   and this interface is designated Standby and is not sending or
   receiving control packets.  The interface will continue to receive
   the Hello packets sent by the Active Interface.  The interface will
   maintain a timer, the Active Interface Timer, with the same interval
   as the RouterDeadInterval.  This timer will be reset whenever an OSPF
   Hello packet is received from the Active Interface to the link.

   Two new events are added to the list of events that cause interface
   state changes: MultipleInterfacesToLink and ActiveInterfaceDead.  The
   descriptions of these events are as follows:

Top      Up      ToC       Page 51 
   MultipleInterfacesToLink
      An interfaces on the router has received a Hello packet from
      another interface on the same router.  One of the interfaces is
      designated as the Active Interface and the other interface is
      designated as a Standby Interface.  The Standby Interface
      transitions to the Standby state.

   ActiveInterfaceDead
      There has been an indication that a Standby Interface is no longer
      on a link with an Active Interface.  The firing of the Active
      Interface Timer is one indication of this event, as it indicates
      that the Standby Interface has not received an OSPF Hello packet
      from the Active Interface for the RouterDeadInterval.  Other
      indications may come from internal notifications, such as the
      Active Interface being disabled through a configuration change.
      Any indication internal to the router, such that the router knows
      the Active Interface is no longer active on the link, can trigger
      the ActiveInterfaceDead event for a Standby Interface.

   Interface state machine additions include:

        State(s):  Waiting, DR Other, Backup, or DR

           Event:  MultipleInterfacesToLink

       New state:  Standby

          Action:  All interface variables are reset and interface
                   timers disabled.  Also, all neighbor connections
                   associated with the interface are destroyed.  This
                   is done by generating the event KillNbr on all
                   associated neighbors.  The Active Interface Timer is
                   started and the interface will listen for OSPF Hello
                   packets from the link's Active Interface.

        State(s):  Standby

           Event:  ActiveInterfaceDead

       New state:  Down

          Action:  The Active Interface Timer is first disabled.  Then
                   the InterfaceUp event is invoked.

                 Standby Interface State Machine Additions

Top      Up      ToC       Page 52 
5.  Security Considerations

   When running over IPv6, OSPFv3 relies on the IP Authentication Header
   (see [IPAUTH]) and the IP Encapsulating Security Payload (see
   [IPESP]) to ensure integrity and authentication/confidentiality of
   protocol packets.  This is described in [OSPFV3-AUTH].

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

   The mechanisms in [OSPFV3-AUTH] do not provide protection against
   compromised, malfunctioning, or misconfigured routers.  Such routers
   can, either accidentally or deliberately, cause malfunctions
   affecting the whole routing domain.  The reader is encouraged to
   consult [GENERIC-THREATS] for a more comprehensive description of
   threats to routing protocols.

6.  Manageability Considerations

   The Management Information Base (MIB) for OSPFv3 is defined in
   [OSPFV3-MIB].

7.  IANA Considerations

   Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA].
   IANA has updated the reference for RFC 2740 to this document.

   Additionally, this document introduces the following IANA
   requirements that were not present in [OSPFV3]:

   o  Reserves the options with the values 0x000040 and 0x000080 for
      migrated OSPFv2 options in the OSPFv3 Options registry defined in
      [OSPF-IANA].  For information on the OSPFv3 Options field, refer
      to Appendix A.2.

   o  Adds the prefix option P-bit with value 0x08 to the OSPFv3 Prefix
      Options registry defined in [OSPF-IANA].  For information on
      OSPFv3 Prefix Options, refer to Appendix A.4.1.1.

Top      Up      ToC       Page 53 
   o  Adds the prefix option DN-bit with value 0x10 to the OSPFv3 Prefix
      Options registry defined in [OSPF-IANA].  For information on
      OSPFv3 Prefix Options, refer to Appendix A.4.1.1.

7.1.  MOSPF for OSPFv3 Deprecation IANA Considerations

   With the deprecation of MOSPF for OSPFv3, the following code points
   are available for reassignment.  Refer to [OSPF-IANA] for information
   on the respective registries.  This document:

   o  Deprecates the MC-bit with value 0x000004 in the OSPFv3 Options
      registry.

   o  Deprecates Group-membership-LSA with value 6 in OSPFv3 LSA
      Function Code registry.

   o  Deprecates MC-bit with value 0x04 in the OSPFv3 Prefix Options
      registry.

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

      Registry Name: OSPFv3 Router Properties Registry
      Reference: RFC 5340
      Registration Procedures: Standards Action

      Registry:
      Value   Description    Reference
      ------  -------------  ---------
      0x01    B-bit          RFC 5340
      0x02    E-bit          RFC 5340
      0x04    V-bit          RFC 5340
      0x08    Deprecated     RFC 5340
      0x10    Nt-bit         RFC 5340

                     OSPFv3 Router Properties Registry

8.  Acknowledgments

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

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

   o  Harold Rabbie for his description of protocol details that needed
      to be clarified for OSPFv3 NSSA support.

Top      Up      ToC       Page 54 
   o  Nic Neate for his pointing out that there needed to be changes for
      unknown LSA types handling in the processing of Database
      Description packets.

   o  Jacek Kwiatkowski for being the first to point out that the V6-
      and R-bits are not taken into account in the OSPFv3 intra-area SPF
      calculation.

   o  Michael Barnes recognized that the support for multiple interfaces
      to a single link was broken (see Section 4.9) and provided the
      description of the current protocol mechanisms.  Abhay Roy
      reviewed and suggested improvements to the mechanisms.

   o  Alan Davey reviewed and commented on document revisions.

   o  Vivek Dubey reviewed and commented on document revisions.

   o  Manoj Goyal and Vivek Dubey complained enough about link-LSAs
      being unnecessary to compel introduction of the LinkLSASuppression
      interface configuration parameter.

   o  Manoj Goyal for pointing out that the next-hop calculation for
      intra-area-prefix-LSAs corresponding to network vertices was
      unclear.

   o  Ramana Koppula reviewed and commented on document revisions.

   o  Paul Wells reviewed and commented on document revisions.

   o  Amir Khan reviewed and commented on document revisions.

   o  Dow Street and Wayne Wheeler commented on the addition of the DN-
      bit to OSPFv3.

   o  Mitchell Erblichs provided numerous editorial comments.

   o  Russ White provided numerous editorial comments.

   o  Kashima Hiroaki provided editorial comments.

   o  Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2
      with respect to precedence and should map it to IPv6 traffic class
      as specified in RFC 2474.  Steve Blake helped with the text.

   o  Faraz Shamin reviewed a late version of the document and provided
      editorial comments.

Top      Up      ToC       Page 55 
   o  Christian Vogt performed the General Area Review Team (Gen-ART)
      review and provided comments.

   o  Dave Ward, Dan Romascanu, Tim Polk, Ron Bonica, Pasi Eronen, and
      Lars Eggert provided comments during the IESG review.  Also,
      thanks to Pasi for the text in Section 5 relating to routing
      threats.

9.  References

9.1.  Normative References

   [DEMAND]           Moy, J., "Extending OSPF to Support Demand
                      Circuits", RFC 1793, April 1995.

   [DIFF-SERV]        Nichols, K., Blake, S., Baker, F., and D. Black,
                      "Definition of the Differentiated Services Field
                      (DS Field) in the IPv4 and IPv6 Headers",
                      RFC 2474, December 1998.

   [DN-BIT]           Rosen, E., Peter, P., and P. Pillay-Esnault,
                      "Using a Link State Advertisement (LSA) Options
                      Bit to Prevent Looping in BGP/MPLS IP Virtual
                      Private Networks (VPNs)", RFC 4576, June 2006.

   [INTFMIB]          McCloghrie, K. and F. Kastenholz, "The Interfaces
                      Group MIB", RFC 2863, June 2000.

   [IP6ADDR]          Hinden, R. and S. Deering, "IP Version 6
                      Addressing Architecture", RFC 4291, February 2006.

   [IPAUTH]           Kent, S., "IP Authentication Header", RFC 4302,
                      December 2005.

   [IPESP]            Kent, S., "IP Encapsulating Security Payload
                      (ESP)", RFC 4303, December 2005.

   [IPV4]             Postal, J., "Internet Protocol", STD 5, RFC 791,
                      September 1981.

   [IPV6]             Deering, S. and R. Hinden, "Internet Protocol,
                      Version 6 (IPv6) Specification", RFC 2460,
                      December 1998.

   [NSSA]             Murphy, P., "The OSPF Not-So-Stubby Area (NSSA)
                      Option", RFC 3101, January 2003.

Top      Up      ToC       Page 56 
   [OSPF-IANA]        Kompella, K. and B. Fenner, "IANA Considerations
                      for OSPF", BCP 130, RFC 4940, July 2007.

   [OSPFV2]           Moy, J., "OSPF Version 2", STD 54, RFC 2328,
                      April 1998.

   [OSPFV3-AUTH]      Gupta, M. and N. Melam, "Authentication/
                      Confidentiality for OSPFv3", RFC 4552, June 2006.

   [RFC-KEYWORDS]     Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.

9.2.  Informative References

   [GENERIC-THREATS]  Barbir, A., Murphy, S., and Y. Yang, "Generic
                      Threats to Routing Protocols", RFC 4593,
                      October 2006.

   [MOSPF]            Moy, J., "Multicast Extensions to OSPF", RFC 1584,
                      March 1994.

   [MTUDISC]          Mogul, J. and S. Deering, "Path MTU discovery",
                      RFC 1191, November 1990.

   [OPAQUE]           Coltun, R., "The OSPF Opaque LSA Option",
                      RFC 2370, July 1998.

   [OSPFV3]           Coltun, R., Ferguson, D., and J. Moy, "OSPF for
                      IPv6", RFC 2740, December 1999.

   [OSPFV3-MIB]       Joyal, D. and V. Manral, "Management Information
                      Base for OSPFv3", Work in Progress,
                      September 2007.

   [SERV-CLASS]       Babiarz, J., Chan, K., and F. Baker,
                      "Configuration Guidelines for DiffServ Service
                      Classes", RFC 4594, August 2006.

Top      Up      ToC       Page 57 
Appendix A.  OSPF Data Formats

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

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

   OSPF packet formats are detailed in Section A.3.

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

A.1.  Encapsulation of OSPF Packets

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

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

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

   o  Use of IPv6 multicast.  Some OSPF messages are multicast when sent
      over broadcast networks.  Two distinct IP multicast addresses are
      used.  Packets sent to these multicast addresses should never be
      forwarded; they are meant to travel a single hop only.  As such,
      the multicast addresses have been chosen with link-local scope and
      packets sent to these addresses should have their IPv6 Hop Limit
      set to 1. b

Top      Up      ToC       Page 58 
      AllSPFRouters
         This multicast address has been assigned the value FF02::5.
         All routers running OSPF should be prepared to receive packets
         sent to this address.  Hello packets are always sent to this
         destination.  Also, certain OSPF protocol packets are sent to
         this address during the flooding procedure.

      AllDRouters
         This multicast address has been assigned the value FF02::6.
         Both the Designated Router and Backup Designated Router must be
         prepared to receive packets destined to this address.  Certain
         OSPF protocol packets are sent to this address during the
         flooding procedure.

   o  OSPF is IP protocol 89.  This number SHOULD be inserted in the
      Next Header field of the encapsulating IPv6 header.

   o  The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that
      OSPF protocol packets are sent with IP precedence set to
      Internetwork Control (B'110') [IPV4].  If routers in the OSPF
      routing domain map their IPv6 Traffic Class octet to the
      Differentiated Services Code Point (DSCP) as specified in
      [DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP
      set to CS6 (B'110000'), as specified in [SERV-CLASS].  In networks
      supporting this mapping, OSPF packets will be given precedence
      over IPv6 data traffic.

A.2.  The Options Field

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

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

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

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

                           The Options field

                             The Options field

   V6-bit
      If this bit is clear, the router/link should be excluded from IPv6
      routing calculations.  See Section 4.8 for details.

   E-bit
      This bit describes the way AS-external-LSAs are flooded, as
      described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2].

   x-Bit
      This bit was previously used by MOSPF (see [MOSPF]), which has
      been deprecated for OSPFv3.  The bit should be set to 0 and
      ignored when received.  It may be reassigned in the future.

   N-bit
      This bit indicates whether or not the router is attached to an
      NSSA as specified in [NSSA].

   R-bit
      This bit (the `Router' bit) indicates whether the originator is an
      active router.  If the router bit is clear, then routes that
      transit the advertising node cannot be computed.  Clearing the
      router bit would be appropriate for a multi-homed host that wants
      to participate in routing, but does not want to forward non-
      locally addressed packets.

   DC-bit
      This bit describes the router's handling of demand circuits, as
      specified in [DEMAND].

Top      Up      ToC       Page 60 
   *-bit
      These bits are reserved for migration of OSPFv2 protocol
      extensions.

A.3.  OSPF Packet Formats

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

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

   The receive processing of OSPF packets is detailed in Section 4.2.2.
   The sending of OSPF packets is explained in Section 4.2.1.

A.3.1.  The OSPF Packet Header

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

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

                          The OSPF Packet Header

   Version #
      The OSPF version number.  This specification documents version 3
      of the OSPF protocol.

Top      Up      ToC       Page 61 
   Type
      The OSPF packet types are as follows.  See Appendix A.3.2 through
      Appendix A.3.6 for details.

            Type   Description
            ---------------------------------
            1      Hello
            2      Database Description
            3      Link State Request
            4      Link State Update
            5      Link State Acknowledgment

   Packet length
      The length of the OSPF protocol packet in bytes.  This length
      includes the standard OSPF header.

   Router ID
      The Router ID of the packet's source.

   Area ID
      A 32-bit number identifying the area to which this packet belongs.
      All OSPF packets are associated with a single area.  Most travel a
      single hop only.  Packets traversing a virtual link are labeled
      with the backbone Area ID of 0.

   Checksum
      OSPF uses the standard checksum calculation for IPv6 applications:
      The 16-bit one's complement of the one's complement sum of the
      entire contents of the packet, starting with the OSPF packet
      header, and prepending a "pseudo-header" of IPv6 header fields, as
      specified in Section 8.1 of [IPV6].  The "Upper-Layer Packet
      Length" in the pseudo-header is set to the value of the OSPF
      packet header's length field.  The Next Header value used in the
      pseudo-header is 89.  If the packet's length is not an integral
      number of 16-bit words, the packet is padded with a byte of zero
      before checksumming.  Before computing the checksum, the checksum
      field in the OSPF packet header is set to 0.

   Instance ID
      Enables multiple instances of OSPF to be run over a single link.
      Each protocol instance would be assigned a separate Instance ID;
      the Instance ID has link-local significance only.  Received
      packets whose Instance ID is not equal to the receiving
      interface's Instance ID are discarded.

Top      Up      ToC       Page 62 
   0
      These fields are reserved.  They SHOULD be set to 0 when sending
      protocol packets and MUST be ignored when receiving protocol
      packets.

A.3.2.  The Hello Packet

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

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

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

                           The OSPF Hello Packet

Top      Up      ToC       Page 63 
   Interface ID
      32-bit number uniquely identifying this interface among the
      collection of this router's interfaces.  For example, in some
      implementations it may be possible to use the MIB-II IfIndex
      ([INTFMIB]).

   Rtr Priority
      This router's Router Priority.  Used in (Backup) Designated Router
      election.  If set to 0, the router will be ineligible to become
      (Backup) Designated Router.

   Options
      The optional capabilities supported by the router, as documented
      in Section A.2.

   HelloInterval
      The number of seconds between this router's Hello packets.

   RouterDeadInterval
      The number of seconds before declaring a silent router down.

   Designated Router ID
      The sending router's view of the identity of the Designated Router
      for this network.  The Designated Router is identified by its
      Router ID.  It is set to 0.0.0.0 if there is no Designated Router.

   Backup Designated Router ID
      The sending router's view of the identity of the Backup Designated
      Router for this network.  The Backup Designated Router is
      identified by its IP Router ID.  It is set to 0.0.0.0 if there is
      no Backup Designated Router.

   Neighbor ID
      The Router IDs of each router on the network with neighbor state
      1-Way or greater.

A.3.3.  The Database Description Packet

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

Top      Up      ToC       Page 64 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
      |      3        |       2       |        Packet Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
      |                           Router ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
      |                             Area ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
      |           Checksum            |  Instance ID  |      0         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
      |       0       |               Options                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
      |        Interface MTU          |      0        |0|0|0|0|0|I|M|MS|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
      |                    DD sequence number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
      |                                                                |
      +-                                                              -+
      |                                                                |
      +-                     An LSA Header                            -+
      |                                                                |
      +-                                                              -+
      |                                                                |
      +-                                                              -+
      |                                                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
      |                       ...                                      |

                   The OSPF Database Description Packet

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

   Options
      The optional capabilities supported by the router, as documented
      in Section A.2.

   Interface MTU
      The size in bytes of the largest IPv6 datagram that can be sent
      out the associated interface without fragmentation.  The MTUs of
      common Internet link types can be found in Table 7-1 of [MTUDISC].

Top      Up      ToC       Page 65 
      Interface MTU should be set to 0 in Database Description packets
      sent over virtual links.

   I-bit
      The Init bit.  When set to 1, this packet is the first in the
      sequence of Database Description packets.

   M-bit
      The More bit.  When set to 1, it indicates that more Database
      Description packets are to follow.

   MS-bit
      The Master/Slave bit.  When set to 1, it indicates that the router
      is the master during the Database Exchange process.  Otherwise,
      the router is the slave.

   DD sequence number
      Used to sequence the collection of Database Description packets.
      The initial value (indicated by the Init bit being set) should be
      unique.  The DD sequence number then increments until the complete
      database for both the master and slave routers have been
      exchanged.

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

A.3.4.  The Link State Request Packet

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

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

   The sending of Link State Request packets is documented in Section
   10.9 of [OSPFV2].  The reception of Link State Request packets is
   documented in Section 10.7 of [OSPFV2].

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

                    The OSPF Link State Request Packet

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

A.3.5.  The Link State Update Packet

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

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

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


                     The OSPF Link State Update Packet

   # LSAs
      The number of LSAs included in this update.

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

A.3.6.  The Link State Acknowledgment Packet

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

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

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

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

                 The OSPF Link State Acknowledgment Packet

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



(page 68 continued on part 4)

Next RFC Part