rfc1433.txt

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


RFC 1433                      Directed ARP                    March 1993


   associated with an entry learned via a routing protocol update is
   NULL if the associated next-hop address matches a routing table entry
   with a NULL next-hop and NULL ARP Helper Address (i.e., the router
   already knows how to resolve the next-hop address).  Otherwise, the
   ARP Helper Address is the IP address of the router that sent the
   routing update.

   Some distance-vector routing protocols (e.g., BGP [3]) provide syntax
   that would permit a router to advertise an address on a foreign IP
   network as a next-hop.  If a router that implements Directed ARP
   procedures advertises a foreign next-hop IP address to a second
   router that does not implement Directed ARP procedures, the second
   router can not use the advertised foreign next-hop.  Depending on the
   details of the routing protocol implementation, it might be
   appropriate for the first router to also advertise a next-hop that is
   not on a foreign IP network (e.g., itself), perhaps at a higher cost.
   Or, if the routing relationship is an administered connection (e.g.,
   BGP relationships are administered TCP/IP connections), the
   administrative procedure could determine whether foreign next-hop IP
   addresses should be advertised.

   A distance-vector routing protocol could advertise that a destination
   is directly reachable by specifying that the router receiving the
   advertisement is, itself, the next-hop to the destination.  In
   addition, the advertised metric for the route might be zero.  If the
   router did not already have a routing table entry that specified the
   advertised destination was local (i.e., NULL next-hop address), the
   router could add the new route with NULL next-hop, and the IP address
   of the router that sent the update as ARP Helper Address.

4.3  Link State Routing Protocol

   A link-state routing protocol provides procedures for routers to
   identify links to other entities (e.g., other routers and networks),
   determine the state or cost of those links, reliably distribute
   link-state information to other routers in the routing domain, and
   calculate routes based on link-state information received from other
   routers.  A router with an interface to two (or more) IP networks via
   the same link level interface is connected to those IP networks via a
   single link, as described above.  If a router could advertise that it
   used the same link to connect to two (or more) IP networks, and would
   perform Directed ARP procedures, routers on either of the IP networks
   could forward packets directly to hosts and routers on both IP
   networks, using Directed ARP procedures to resolve addresses on the
   foreign IP network.  With Directed ARP, the cost of the direct path
   to the foreign IP network would be less than the cost of the path
   through the router with addresses on both IP networks.




Garrett, Hagan & Wong                                          [Page 13]

RFC 1433                      Directed ARP                    March 1993


   To benefit from Directed ARP procedures, the link-state routing
   protocol must include procedures for a router to advertise
   connectivity to multiple IP networks via the same link, and the
   routing table calculation process must include procedures to
   calculate ARP Helper Addresses and procedures to accurately calculate
   the reduced cost of the path to a foreign IP network reached directly
   via Directed ARP procedures.

   The Shortest Path First algorithm for calculating least cost routes
   is based on work by Dijkstra [7], and was first used in a routing
   protocol by the ARPANET, as described by McQuillan [8].  A router
   constructs its routing table by building a shortest path tree, with
   itself as root.  The process is iterative, starting with no entries
   on the shortest path tree, and the router, itself, as the only entry
   in a list of candidate vertices.  The router then loops on the
   following two steps.

     1.  Remove the entry from the candidate list that is closest to
         root, and add it to the shortest path tree.

     2.  Examine the link state advertisement from the entry added to
         the shortest path tree in step 1.  For each neighbor (i.e.,
         router or IP network to which a link connects)

            - If the neighbor is already on the shortest path tree, do
              nothing.

            - If the neighbor is on the candidate list, recalculate the
              distance from root to the neighbor.  Also recalculate the
              next-hop(s) to the neighbor.

            - If the neighbor is not on the candidate list, calculate
              the distance from root to the neighbor and the next-hop(s)
              from root to the neighbor, and add the neighbor to the
              candidate list.

The process terminates when there are no entries on the candidate list.

To take advantage of Directed ARP procedures, the link-state protocol
must provide procedures to advertise that a router accesses two or more
IP networks via the same link.  In addition, the Shortest Path First
calculation is modified to calculate ARP Helper Addresses and recognize
path cost reductions achieved via Directed ARP.

     1.  If a neighbor under consideration is an IP network, and its
         parent (i.e., the entry added to the shortest path tree in step
         1, above) has advertised that the neighbor is reached via the
         same link as a network that is already on the shortest path



Garrett, Hagan & Wong                                          [Page 14]

RFC 1433                      Directed ARP                    March 1993


         tree, the distance from root and next-hop(s) from root to the
         neighbor are the same as the distance and next-hop(s)
         associated with the network already on the shortest path tree.
         If the ARP Helper Address associated with the network that is
         already on the shortest path tree is not NULL, the neighbor
         also inherits the ARP Helper Address from the network that is
         already on the shortest path tree.

     2.  If the calculated next-hop to the neighbor is not NULL, the
         neighbor inherits the ARP Helper Address from its parent.
         Otherwise, except as described in item 1, the ARP Helper
         Address is the IP address of the next-hop to the neighbor's
         parent.  Note that the next-hop to root is NULL.

   For each router or IP network on the shortest path tree, the Shortest
   Path First algorithm described above must calculate one or more
   next-hops that can be used to access the router or IP network.  A
   router that advertises a link to an IP network must include an IP
   address that can be used by other routers on the IP network when
   using the router as a next-hop.  A router might advertise that it was
   connected to two IP networks via the same link by advertising the
   same next-hop IP address for access from both IP networks.  To
   accommodate the address resolution constraints of routers on both IP
   networks the router might advertise two IP addresses (one from each
   IP network) as next-hop IP addresses for access from both IP
   networks.

5.  Robustness

   Hosts and routers can use Directed ARP to resolve third-party next-
   hop addresses; i.e., next-hop addresses learned from a routing
   protocol peer or current next-hop router.  Undetected failure of a
   third party next-hop can result in a routing "black hole".  To avoid
   "black holes", host requirements [5] specify that a host "...MUST be
   able to detect the failure of a 'next-hop' gateway that is listed in
   its route cache and to choose an alternate gateway."  A host may
   receive feedback from protocol layers above IP (e.g., TCP) that
   indicates the status of a next-hop router, and may use other
   procedures (e.g., ICMP echo) to test the status of a next-hop router.
   But the complexity of routing is borne by routers, whose routing
   information must be consistent with the information known to their
   peers.  Routing protocols such as BGP [3], OSPF [4], and others,
   require that routers must stand behind routing information that they
   advertise.  Routers tag routing information with the IP address of
   the router that advertised the information.  If the information
   becomes invalid, the router that advertised the information must
   advertise that the old information is no longer valid.  If a source
   of routing information becomes unavailable, all information received



Garrett, Hagan & Wong                                          [Page 15]

RFC 1433                      Directed ARP                    March 1993


   from that source must be marked as no longer valid.  The complexity
   of dynamic routing protocols stems from procedures to ensure routers
   either receive routing updates sent by a peer, or are able to
   determine that they did not receive the updates (e.g., because
   connectivity to the peer is no longer available).

   Third-party next-hops can also result in "black holes" if the
   underlying link layer network connectivity is not transitive.  For
   example, SMDS filters [9] could be administered to permit
   communication between the SMDS addresses of router R1 and router R2,
   and between the SMDS addresses of router R2 and router R3, and to
   block communication between the SMDS addresses of router R1 and
   router R3.  Router R2 could advertise router R3 as a next-hop to
   router R1, but SMDS filters would prevent direct communication
   between router R1 and router R3.  Non-symmetric filters might permit
   router R3 to send packets to router R1, but block packets sent by
   router R1 addressed to router R3.

   A host or router could verify link level connectivity with a next-hop
   router by sending an ICMP echo to the link level address of the
   next-hop router.  (Note that the ICMP echo is sent directly to the
   link level address of the next-hop router, and is not routed to the
   IP address of the next-hop router.  If the ICMP echo is routed, it
   may follow a path that does not verify link level connectivity.) This
   test could be performed before adding the associated routing table
   entry, or before the first use of the routing table entry.  Detection
   of subsequent changes in link level connectivity is a dynamic routing
   protocol issue and is beyond the scope of this memo.

References

   [1] Piscitello, D., and J. Lawrence, "The Transmission of IP
       Datagrams over the SMDS Service", RFC 1209, Bell Communications
       Research, March 1991.

   [2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
       Converting Network Protocol Addresses to 48.bit Ethernet Address
       for Transmission on Ethernet Hardware", RFC 826, Symbolics, Inc.,
       November 1982.

   [3] Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-
       3)", RFC 1267, cisco Systems and IBM T. J. Watson Research
       Center, October 1991.

   [4] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.

   [5] Braden, R., editor, "Requirements for Internet Hosts --
       Communication Layers", STD 3, RFC 1122, USC/Information Sciences



Garrett, Hagan & Wong                                          [Page 16]

RFC 1433                      Directed ARP                    March 1993


       Institute, October 1989.

   [6] Postel, J., "Internet Control Message Protocol - DARPA Internet
       Program Protocol Specification", STD 5, RFC 792, USC/Information
       Sciences Institute, September 1981.

   [7] Dijkstra, E. W., "A Note on Two Problems in Connection with
       Graphs", Numerische Mathematik, Vol. 1, pp. 269-271, 1959.

   [8] McQuillan, J. M., I. Richer, and E. C. Rosen, "The New Routing
       Algorithm for the ARPANET", IEEE Transactions on Communications,
       Vol. COM-28, May 1980.

   [9] "Generic System Requirements In Support of Switched Multi-
       megabit Data Service", Technical Reference TR-TSV-000772, Bell
       Communications Research Technical Reference, Issue 1, May 1991.



































Garrett, Hagan & Wong                                          [Page 17]

RFC 1433                      Directed ARP                    March 1993


Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   John Garrett
   AT&T Bell Laboratories
   184 Liberty Corner Road
   Warren, N.J. 07060-0906

   Phone: [phone]
   EMail: [e-mail]


   John Dotts Hagan
   University of Pennsylvania
   Suite 221A
   3401 Walnut Street
   Philadelphia, PA 19104-6228

   Phone: [phone]
   EMail: [e-mail]


   Jeffrey A. Wong
   AT&T Bell Laboratories
   184 Liberty Corner Road
   Warren, N.J. 07060-0906

   Phone: [phone]
   EMail: [e-mail]



















Garrett, Hagan & Wong                                          [Page 18]