rfc2740.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Designated Routers on broadcast and NBMA links. The decision as to
   which neighbor relationships become adjacencies, along with the basic
   ideas behind inter-area routing, importing external information in
   AS-external-LSAs and the various routing calculations are also the
   same.

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

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

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



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


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

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

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

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

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

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

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

3.1.  Protocol data structures

   The major OSPF data structures are the same for both IPv4 and IPv6:
   areas, interfaces, neighbors, the link-state database and the routing
   table. The top-level data structures for IPv6 remain those listed in
   Section 5 of [Ref1], with the following modifications:

   o  All LSAs with known LS type and AS flooding scope appear in the
      top-level data structure, instead of belonging to a specific area
      or link. AS-external-LSAs are the only LSAs defined by this
      specification which have AS flooding scope.  LSAs with unknown LS
      type, U-bit set to 1 (flood even when unrecognized) and AS
      flooding scope also appear in the top-level data structure.







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


3.1.1.  The Area Data structure

   The IPv6 area data structure contains all elements defined for IPv4
   areas in Section 6 of [Ref1]. In addition, all LSAs of known type
   which have area flooding scope are contained in the IPv6 area data
   structure. This always includes the following LSA types: router-LSAs,
   network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs and
   intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1
   (flood even when unrecognized) and area scope also appear in the area
   data structure. IPv6 routers implementing MOSPF add group-
   membership-LSAs to the area data structure. Type-7-LSAs belong to an
   NSSA area's data structure.

3.1.2.  The Interface Data structure

   In OSPF for IPv6, an interface connects a router to a link.  The IPv6
   interface structure modifies the IPv4 interface structure (as defined
   in Section 9 of [Ref1]) as follows:

   Interface ID
      Every interface is assigned an Interface ID, which uniquely
      identifies the interface with the router. For example, some
      implementations may be able to use the MIB-II IfIndex ([Ref3]) as
      Interface ID. The Interface ID appears in Hello packets sent out
      the interface, the link-local-LSA originated by router for the
      attached link, and the router-LSA originated by the router-LSA for
      the associated area. It will also serve as the Link State ID for
      the network-LSA that the router will originate for the link if the
      router is elected Designated Router.

   Instance ID
      Every interface is assigned an Instance ID. This should default to
      0, and is only necessary to assign differently on those links that
      will contain multiple separate communities of OSPF Routers. For
      example, suppose that there are two communities of routers on a
      given ethernet segment that you wish to keep separate.

      The first community is given an Instance ID of 0, by assigning 0
      as the Instance ID of all its routers' interfaces to the ethernet.
      An Instance ID of 1 is assigned to the other routers' interfaces
      to the ethernet. The OSPF transmit and receive processing (see
      Section 3.2) will then keep the two communities separate.

   List of LSAs with link-local scope
      All LSAs with link-local scope and which were originated/flooded
      on the link belong to the interface structure which connects to
      the link. This includes the collection of the link's link-LSAs.




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


   List of LSAs with unknown LS type
      All LSAs with unknown LS type and U-bit set to 0 (if unrecognized,
      treat the LSA as if it had link-local flooding scope) are kept in
      the data structure for the interface that received the LSA.

   IP interface address
      For IPv6, the IPv6 address appearing in the source of OSPF packets
      sent out the interface is almost always a link-local address. The
      one exception is for virtual links, which must use one of the
      router's own site-local or global IPv6 addresses as IP interface
      address.

   List of link prefixes
      A list of IPv6 prefixes can be configured for the attached link.
      These will be advertised by the router in link-LSAs, so that they
      can be advertised by the link's Designated Router in intra-area-
      prefix-LSAs.

   In OSPF for IPv6, each router interface has a single metric,
   representing the cost of sending packets out the interface.  In
   addition, OSPF for IPv6 relies on the IP Authentication Header (see
   [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to
   ensure integrity and authentication/confidentiality of routing
   exchanges.  For that reason, AuType and Authentication key are not
   associated with IPv6 OSPF interfaces.

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

3.1.3.  The Neighbor Data Structure

   The neighbor structure performs the same function in both IPv6 and
   IPv4. Namely, it collects all information required to form an
   adjacency between two routers, if an adjacency becomes necessary.
   Each neighbor structure is bound to a single OSPF interface. The
   differences between the IPv6 neighbor structure and the neighbor
   structure defined for IPv4 in Section 10 of [Ref1] are:

   Neighbor's Interface ID
      The Interface ID that the neighbor advertises in its Hello Packets
      must be recorded in the neighbor structure. The router will
      include the neighbor's Interface ID in the router's router-LSA
      when either a) advertising a point-to-point link to the neighbor
      or b) advertising a link to a network where the neighbor has
      become Designated Router.



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


   Neighbor IP address
      Except on virtual links, the neighbor's IP address will be an IPv6
      link-local address.

   Neighbor's Designated Router
      The neighbor's choice of Designated Router is now encoded as a
      Router ID, instead of as an IP address.

   Neighbor's Backup Designated Router
      The neighbor's choice of Designated Router is now encoded as a
      Router ID, instead of as an IP address.

   Neighbor states, events, and the neighbor state machine remain
   unchanged from IPv4, and are documented in Sections 10.1, 10.2 and
   10.3 of [Ref1] respectively. The decision as to which adjacencies to
   form also remains unchanged from the IPv4 logic documented in Section
   10.4 of [Ref1].

3.2.  Protocol Packet Processing

   OSPF for IPv6 runs directly over IPv6's network layer. As such, it is
   encapsulated in one or more IPv6 headers, with the Next Header field
   of the immediately encapsulating IPv6 header set to the value 89.

   As for IPv4, in IPv6 OSPF routing protocol packets are sent along
   adjacencies only (with the exception of Hello packets, which are used
   to discover the adjacencies). OSPF packet types and functions are the
   same in both IPv4 and IPv4, encoded by the

   Type field of the standard OSPF packet header.

3.2.1.  Sending protocol packets

   When an IPv6 router sends an OSPF routing protocol packet, it fills
   in the fields of the standard OSPF for IPv6 packet header (see
   Section A.3.1) as follows:

   Version #
      Set to 3, the version number of the protocol as documented in this
      specification.

   Type
      The type of OSPF packet, such as Link state Update or Hello
      Packet.

   Packet length
      The length of the entire OSPF packet in bytes, including the
      standard OSPF packet header.



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


   Router ID
      The identity of the router itself (who is originating the packet).

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

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

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

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

   The sending of Link State Request Packets and Link State
   Acknowledgment Packets remains unchanged from the IPv4 procedures
   documented in Sections 10.9 and 13.5 of [Ref1] respectively. Sending
   Hello Packets is documented in Section 3.2.1.1, and the sending of
   Database Description Packets in Section 3.2.1.2. The sending of Link
   State Update Packets is documented in Section 3.5.2.

3.2.1.1.  Sending Hello packets

   IPv6 changes the way OSPF Hello packets are sent in the following
   ways (compare to Section 9.5 of [Ref1]):

   o  Before the Hello Packet is sent out an interface, the interface's
      Interface ID must be copied into the Hello Packet.

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

   o  The choice of Designated Router and Backup Designated Router are
      now indicated within Hellos by their Router IDs, instead of by
      their IP interface addresses.      Advertising the Designated
      Router (or Backup Designated Router) as 0.0.0.0 indicates that the