rfc2080.txt

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

   be generated for every directly-connected network.  Split Horizon
   processing is done when generating triggered updates as well as
   normal updates (see section 2.6).  If, after Split Horizon processing
   for a given network, a changed route will appear unchanged on that
   network (e.g., it appears with an infinite metric), the route need
   not be sent.  If no routes need be sent on that network, the update
   may be omitted.  Once all of the triggered updates have been
   generated, the route change flags should be cleared.

   If input processing is allowed while output is being generated,
   appropriate interlocking must be done.  The route change flags should
   not be changed as a result of processing input while a triggered
   update message is being generated.

   The only difference between a triggered update and other update
   messages is the possible omission of routes that have not changed.
   The remaining mechanisms, described in the next section, must be
   applied to all updates.

2.5.2  Generating Response Messages

   This section describes how a Response message is generated for a
   particular directly-connected network:

   The IPv6 source address must be a link-local address of the possible
   addresses of the sending router's interface, except when replying to
   a unicast Request Message from a port other than the RIPng port.  In
   the latter case, the source address must be a globaly valid address.
   In the former case, it is important to use a link-local address
   because the source address is put into routing tables (as the next
   hop) in the routers which receive this Response.  If an incorrect
   source address is used, other routers may be unable to route
   datagrams.  Sometimes routers are set up with multiple IPv6 addresses
   on a single physical interface.  Normally, this means that several
   logical IPv6 networks are being carried over one physical medium.  It
   is possible that a router may have multiple link-local addresses for



Malkin & Minnear            Standards Track                    [Page 15]

RFC 2080                     RIPng for IPv6                 January 1997


   a single interface. In this case, the router must only originate a
   single Response message with a source address of the designated
   link-local address for a given interface.  The choice of which link-
   local address to use should only change when the current choice is no
   longer valid.  This is necessary because nodes receiving Response
   messages use the source address to identify the sender.  If multiple
   packets from the same router contain different source addresses,
   nodes will assume they come from different routers, leading to
   undesirable behavior.

   Set the version number to the current version of RIPng.  The version
   described in this document is version 1.  Set the command to
   Response.  Set the bytes labeled "must be zero" to zero.  Start
   filling in RTEs.  Recall that the maximum datagram size is limited by
   the network's MTU.  When there is no more space in the datagram, send
   the current Response and start a new one.

   To fill in the RTEs, examine each route in the routing table.  Routes
   to link-local addresses must never be included in an RTE.  If a
   triggered update is being generated, only entries whose route change
   flags are set need be included.  If, after Split Horizon processing,
   the route should not be included, skip it.  If the route is to be
   included, then the destination prefix, prefix length, and metric are
   put into the RTE.  The route tag is filled in as defined in section
   2.1.  Routes must be included in the datagram even if their metrics
   are infinite.

2.6  Split Horizon

   Split Horizon is a algorithm for avoiding problems caused by
   including routes in updates sent to the gateway from which they were
   learned.  The basic split horizon algorithm omits routes learned from
   one neighbor in updates sent to that neighbor.  In the case of a
   broadcast network, all routes learned from any neighbor on that
   network are omitted from updates sent on that network.

   Split Horizon with Poisoned Reverse (more simply, Poison Reverse)
   does include such routes in updates, but sets their metrics to
   infinity.  In effect, advertising the fact that there routes are not
   reachable.  This is the preferred method of operation; however,
   implementations should provide a per-interface control allowing no
   horizoning, split horizoning, and poisoned reverse to be selected.

   For a theoretical discussion of Split Horizon and Poison Reverse, and
   why they are needed, see section 2.1.1 of [1].






Malkin & Minnear            Standards Track                    [Page 16]

RFC 2080                     RIPng for IPv6                 January 1997


3. Control Functions

   This section describes administrative controls.  These are not part
   of the protocol per se; however, experience with existing networks
   suggests that they are important.  Because they are not a necessary
   part of the protocol, they are considered optional.  However, it is
   strongly recommend that at least some of them be included in every
   implementation.  These controls are intended primarily to allow RIPng
   to be connected to networks whose routing may be unstable or subject
   to errors.  Here are some examples:

   - It is sometimes desirable to restrict the routers from which
     updates will be accepted, or to which updates will be sent.  This
     is usually done for administrative, routing policy reasons.

   - A number of sites limit the set of networks that they allow in
     Response messages.  Organization A may have a connection to
     organization B that they use for direct communication.  For security
     or performance reasons A may not be willing to give other
     organizations access to that connection.  In such a case, A should
     not include B's networks in updates that A sends to third parties.

   Here are some typical controls.  Note, however, that the RIPng
   protocol does not require these or any other controls.

   - A neighbor list which allows the network administrator to be able
     to define a list of neighbors for each router.  A router would
     accept response messages only from routers on its list of
     neighbors.  A similar list for target routers should also be
     available to the administrator.  By default, no restrictions are
     defined.

   - A filter for specific destinations would permit the network admin-
     istrator to be able to specify a list of destination prefixes to
     allow or disallow.  The list would be associated with a particular
     interface in the incoming and/or outgoing directions.  Only allowed
     networks would be mentioned in Response messages going out or
     processed in Response messages coming in.  If a list of allowed
     prefixes is specified, all other prefixes are disallowed.  If a list
     of disallowed prefixes is specified, all other prefixes are
     allowed.  By default, no filters are applied.










Malkin & Minnear            Standards Track                    [Page 17]

RFC 2080                     RIPng for IPv6                 January 1997


4. Security Considerations

   Since RIPng runs over IPv6, RIPng relies on the IP Authentication
   Header (see [11]) and the IP Encapsulating Security Payload (see
   [12]) to ensure integrity and authentication/confidentiality of
   routing exchanges.

References

   [1] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
       University, June 1988.

   [2] Malkin, G., "RIP Version 2 - Carrying Additional Information",
       RFC 1723, Xylogics, Inc., November, 1994.

   [3] Hinden, R., "IP Next Generation Overview",
       Work in Progress.

   [4] Bellman, R., "Dynamic Programming", Princeton University
       Press, Princeton, N.J., 1957.

   [5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-
       Hall, Englewood Cliffs, N.J., 1987.

   [6] Braden, R., and J. Postel, "Requirements for Internet Gateways",
       USC/Information Sciences Institute, STD 4, RFC 1009, June 1987.

   [7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
       "Pup: An Internetwork Architecture", IEEE Transactions on Commu-
       nications, April 1980.

   [8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
       Princeton University Press, Princeton, N.J., 1962.

   [9] Xerox Corp., "Internet Transport Protocols", Xerox System Inte-
       gration Standard XSIS 028112, December 1981.

   [10] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
        for IP Version 6 (IPv6)", RFC 1970, August 1996.

   [11] Atkinson, R., "IP Authentication Header", RFC 1826
        Naval Research Laboratory, August 1995.









Malkin & Minnear            Standards Track                    [Page 18]

RFC 2080                     RIPng for IPv6                 January 1997


   [12] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
        RFC 1827, Naval Research Laboratory, August 1995.

   [13] Floyd, S., and Jacobson, V., "The Synchronization of Periodic
        Routing Messages", Proceedings of ACM SIGCOMM '93, September
        1993.

Authors' Addresses

   Gary Scott Malkin
   Xylogics, Inc.
   53 Third Avenue
   Burlington, MA 01803

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


   Robert E. Minnear
   Ipsilon Networks, Inc.
   2191 E. Bayshore Road, Suite 100
   Palo Alto, CA 94303

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


























Malkin & Minnear            Standards Track                    [Page 19]