rfc2740.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,446 行 · 第 1/5 页

       only. Used for Router-LSAs, Network-LSAs, Inter-Area-Prefix-
       LSAs, Inter-Area-Router-LSAs and Intra-Area-Prefix-LSAs.

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

2.4.  Explicit support for multiple instances per link

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

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

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

2.5.  Use of link-local addresses

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

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

   On virtual links, global scope or site-local IP addresses must be
   used as the source for OSPF protocol packets.




Coltun, et al.              Standards Track                     [Page 6]

RFC 2740                     OSPF for IPv6                 December 1999


   Link-local addresses appear in OSPF Link-LSAs (see Section 3.4.3.6).
   However, link-local addresses are not allowed in other OSPF LSA
   types.  In particular, link-local addresses must not be advertised in
   inter-area-prefix-LSAs (Section 3.4.3.3), AS-external-LSAs (Section
   3.4.3.5) or intra-area-prefix-LSAs (Section 3.4.3.7).

2.6.  Authentication changes

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

   When running over IPv6, OSPF relies on the IP Authentication Header
   (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20])
   to ensure integrity and authentication/confidentiality of routing
   exchanges.

   Protection of OSPF packet exchanges against accidental data
   corruption is provided by the standard IPv6 16-bit one's complement
   checksum, covering the entire OSPF packet and prepended IPv6 pseudo-
   header (see Section A.3.1).

2.7.  Packet format changes

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

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

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

   o  The Options field in Hello Packets and Database description Packet
      has been expanded to 24-bits.

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

   o  The Hello packet now contains no address information at all, and
      includes an Interface ID which the originating router has assigned
      to uniquely identify (among its own interfaces) its interface to
      the link.  This Interface ID becomes the Netowrk-LSA's Link State
      ID, should the router become Designated-Router on the link.






Coltun, et al.              Standards Track                     [Page 7]

RFC 2740                     OSPF for IPv6                 December 1999


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

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

2.8.  LSA format changes

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

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

   o  The Options field has been removed from the LSA header, expanded
      to 24 bits, and moved into the body of Router-LSAs, Network-LSAs,
      Inter-Area-Router-LSAs and Link-LSAs. See Section A.2 for details.

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

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

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

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






Coltun, et al.              Standards Track                     [Page 8]

RFC 2740                     OSPF for IPv6                 December 1999


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

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

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

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

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

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

   o  A new LSA called the Intra-Area-Prefix-LSA has been introduced.
      This LSA carries all IPv6 prefix information that in IPv4 is
      included in Router-LSAs and Network-LSAs.  See Section A.4.9 for
      details.





Coltun, et al.              Standards Track                     [Page 9]

RFC 2740                     OSPF for IPv6                 December 1999


   o  Inclusion of a forwarding address in AS-external-LSAs is now
      optional, as is the inclusion of an external route tag (see
      [Ref5]). In addition, AS-external-LSAs can now reference another
      LSA, for inclusion of additional route attributes that are outside
      the scope of the OSPF protocol itself. For example, this can be
      used to attach BGP path attributes to external routes as proposed
      in [Ref10].

2.9.  Handling unknown LSA types

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

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

2.10.  Stub area support

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

   In OSPF for IPv6, the concept of stub areas is retained. In IPv6, of
   the mandatory LSA types, stub areas carry only router-LSAs, network-
   LSAs, Inter-Area-Prefix-LSAs, Link-LSAs, and Intra-Area-Prefix-LSAs.
   This is the IPv6 equivalent of the LSA types carried in IPv4 stub
   areas: router-LSAs, network-LSAs and type 3 summary-LSAs.

   However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS types
   to be labeled "Store and flood the LSA, as if type understood" (see
   the U-bit in Section A.4.2.1). Uncontrolled introduction of such LSAs
   could cause a stub area's link-state database to grow larger than its
   component routers' capacities.

   To guard against this, the following rule regarding stub areas has
   been established: an LSA whose LS type is unrecognized may only be
   flooded into/throughout a stub area if both a) the LSA has area or
   link-local flooding scope and b) the LSA has U-bit set to 0. See
   Section 3.5 for details.




Coltun, et al.              Standards Track                    [Page 10]

RFC 2740                     OSPF for IPv6                 December 1999


2.11.  Identifying neighbors by Router ID

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

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

   The Router ID of 0.0.0.0 is reserved, and should not be used.