rfc2740.txt

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

      Designated Router (or Backup Designated Router) has not yet been
      chosen.




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


   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: The E-bit is set
      if and only if the interface attaches to a non-stub area, the N-
      bit is set if and only if the interface attaches to an NSSA area
      (see [Ref9]), and the DC- bit is set if and only if the router
      wishes to suppress the sending of future Hellos over the interface
      (see [Ref11]). 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 [Ref1].

3.2.1.2.  Sending Database Description Packets

   The sending of Database Description packets differs from Section 10.8
   of [Ref1] 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: The MC-bit is set if and only if the router is
      forwarding multicast datagrams according to the MOSPF
      specification in [Ref7], and the DC-bit is set if and only if the
      router wishes to suppress the sending of Hellos over the interface
      (see [Ref11]).  Unrecognized bits in the Database Description
      Packet's Options field should be cleared.

3.2.2.  Receiving protocol packets

   Whenever an OSPF protocol packet is received by the router it is
   marked with the interface it was received on.  For routers that have
   virtual links configured, it may not be immediately obvious which
   interface to associate the packet with.  For example, consider the
   Router RT11 depicted in Figure 6 of [Ref1].  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:

   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), or one of the IP multicast
      addresses AllSPFRouters or AllDRouters.



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


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

   o  Any encapsulating IP Authentication Headers (see [Ref19]) and the
      IP Encapsulating Security Payloads (see [Ref20]) must be processed
      and/or verified to ensure integrity and
      authentication/confidentiality of OSPF routing exchanges.

   o  Locally originated packets should not be passed on to OSPF.  That
      is, the source IPv6 address should be examined to make sure this
      is not a multicast packet that the router itself generated.

   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 interface.  If they do not, the
   packet should be discarded:

   o  The version number field must specify protocol version 3.

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

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

      (1)   Match the Area ID of the receiving interface. In
            this case, unlike for IPv4, the IPv6 source
            address is not restricted to lie on the same IP
            subnet as the receiving interface. IPv6 OSPF runs
            per-link, instead of per-IP-subnet.

      (2)   Indicate the backbone.  In this case, the packet
            has been sent over a virtual link.  The receiving
            router must be an area border router, and the
            Router ID specified in the packet (the source
            router) must be the other end of a configured
            virtual link.  The receiving interface must also
            attach to the virtual link's configured Transit
            area.  If all of these checks succeed, the packet
            is accepted and is from now on associated with
            the virtual link (and the backbone area).

   o  The Instance ID specified in the OSPF header must match the
      receiving interface's Instance ID.





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


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

   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 Protocol.  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 the 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 remains
   unchanged from the IPv4 procedures documented in Sections 10.6, 10.7
   and 13.7 of [Ref1] respectively. The receiving of Hello Packets is
   documented in Section 3.2.2.1, and the receiving of Link State Update
   Packets is documented in Section 3.5.1.

3.2.2.1.  Receiving Hello Packets

   The receive processing of Hello Packets differs from Section 10.5 of
   [Ref1] 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.

   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.

3.3.  The Routing table Structure

   The routing table used by OSPF for IPv4 is defined in Section 11 of
   [Ref1]. 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 3.8).




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


   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 [Ref1])
   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 router.

   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 Section
   A.4.9).

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

3.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 and AS-external-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-



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


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

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

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

   Options
      The Options field has been removed from the standard 20 byte LSA
      header, and 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 Section A.2). In addition 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 the top two bits encoding flooding scope and the next bit
      encoding the handling of unknown LS types.  See Section A.4.2.1
      for the current coding of the LS type field.

   Link State ID
      Link State ID remains at 32 bits in length, but except for
      network-LSAs and link-LSAs, 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.



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


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