home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2080 < prev    next >
Text File  |  1997-01-09  |  48KB  |  1,068 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          G. Malkin
  8. Request for Comments: 2080                                      Xylogics
  9. Category: Standards Track                                     R. Minnear
  10. nn                                                        Ipsilon
  11. Networks
  12.                                                             January 1997
  13.  
  14.                              RIPng for IPv6
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    This document specifies a routing protocol for an IPv6 internet.  It
  27.    is based on protocols and algorithms currently in wide use in the
  28.    IPv4 Internet.
  29.  
  30.    This specification represents the minimum change to the Routing
  31.    Information Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723
  32.    [2], necessary for operation over IPv6 [3].
  33.  
  34. Acknowledgements
  35.  
  36.    This document is a modified version of RFC 1058, written by Chuck
  37.    Hedrick [1].  The modifications reflect RIP-2 and IPv6 enhancements,
  38.    but the original wording is his.
  39.  
  40.    We'd like to thank Dennis Ferguson and Thomas Narten for their input.
  41.  
  42. Table of Contents
  43.  
  44.    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  45.    1.1   Theoretical Underpinnings  . . . . . . . . . . . . . . . . .  3
  46.    1.2   Limitations of the Protocol  . . . . . . . . . . . . . . . .  3
  47.    2.  Protocol Specification . . . . . . . . . . . . . . . . . . . .  4
  48.    2.1   Message Format . . . . . . . . . . . . . . . . . . . . . . .  5
  49.    2.1.1   Next Hop . . . . . . . . . . . . . . . . . . . . . . . . .  7
  50.    2.2   Addressing Considerations  . . . . . . . . . . . . . . . . .  8
  51.    2.3   Timers . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  52.    2.4   Input Processing . . . . . . . . . . . . . . . . . . . . . . 10
  53.    2.4.1   Request Messages . . . . . . . . . . . . . . . . . . . . . 10
  54.    2.4.2   Response Messages  . . . . . . . . . . . . . . . . . . . . 11
  55.  
  56.  
  57.  
  58. Malkin & Minnear            Standards Track                     [Page 1]
  59.  
  60. RFC 2080                     RIPng for IPv6                 January 1997
  61.  
  62.  
  63.    2.5   Output Processing  . . . . . . . . . . . . . . . . . . . . . 14
  64.    2.5.1   Triggered Updates  . . . . . . . . . . . . . . . . . . . . 14
  65.    2.5.2   Generating Response Messages . . . . . . . . . . . . . . . 15
  66.    2.6   Split Horizon  . . . . . . . . . . . . . . . . . . . . . . . 16
  67.    3.  Control Functions  . . . . . . . . . . . . . . . . . . . . . . 17
  68.    4.  Security Considerations. . . . . . . . . . . . . . . . . . . . 18
  69.    References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
  70.    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
  71.  
  72. 1. Introduction
  73.  
  74.    This memo describes one protocol in a series of routing protocols
  75.    based on the Bellman-Ford (or distance vector) algorithm.  This
  76.    algorithm has been used for routing computations in computer networks
  77.    since the early days of the ARPANET.  The particular packet formats
  78.    and protocol described here are based on the program "routed," which
  79.    is included with the Berkeley distribution of Unix.
  80.  
  81.    In an international network, such as the Internet, it is very
  82.    unlikely that a single routing protocol will used for the entire
  83.    network.  Rather, the network will be organized as a collection of
  84.    Autonomous Systems (AS), each of which will, in general, be
  85.    administered by a single entity.  Each AS will have its own routing
  86.    technology, which may differ among AS's.  The routing protocol used
  87.    within an AS is referred to as an Interior Gateway Protocol (IGP).  A
  88.    separate protocol, called an Exterior Gateway Protocol (EGP), is used
  89.    to transfer routing information among the AS's.  RIPng was designed
  90.    to work as an IGP in moderate-size AS's.  It is not intended for use
  91.    in more complex environments.  For information on the context into
  92.    which RIP version 1 (RIP-1) is expected to fit, see Braden and Postel
  93.    [6].
  94.  
  95.    RIPng is one of a class of algorithms known as Distance Vector
  96.    algorithms.  The earliest description of this class of algorithms
  97.    known to the author is in Ford and Fulkerson [8].  Because of this,
  98.    they are sometimes known as Ford-Fulkerson algorithms.  The term
  99.    Bellman-Ford is also used, and derives from the fact that the
  100.    formulation is based on Bellman's equation [4].  The presentation in
  101.    this document is closely based on [5].  This document contains a
  102.    protocol specification.  For an introduction to the mathematics of
  103.    routing algorithms, see [1].  The basic algorithms used by this
  104.    protocol were used in computer routing as early as 1969 in the
  105.    ARPANET.  However, the specific ancestry of this protocol is within
  106.    the Xerox network protocols.  The PUP protocols [7] used the Gateway
  107.    Information Protocol to exchange routing information.  A somewhat
  108.    updated version of this protocol was adopted for the Xerox Network
  109.    Systems (XNS) architecture, with the name Routing Information
  110.    Protocol [9].  Berkeley's routed is largely the same as the Routing
  111.  
  112.  
  113.  
  114. Malkin & Minnear            Standards Track                     [Page 2]
  115.  
  116. RFC 2080                     RIPng for IPv6                 January 1997
  117.  
  118.  
  119.    Information Protocol, with XNS addresses replaced by a more general
  120.    address format capable of handling IPv4 and other types of address,
  121.    and with routing updates limited to one every 30 seconds.  Because of
  122.    this similarity, the term Routing Information Protocol (or just RIP)
  123.    is used to refer to both the XNS protocol and the protocol used by
  124.    routed.
  125.  
  126. 1.1  Theoretical Underpinnings
  127.  
  128.    An introduction to the theory and math behind Distance Vector
  129.    protocols is provided in [1].  It has not been incorporated in this
  130.    document for the sake of brevity.
  131.  
  132. 1.2  Limitations of the Protocol
  133.  
  134.    This protocol does not solve every possible routing problem.  As
  135.    mentioned above, it is primarily intended for use as an IGP in
  136.    networks of moderate size.  In addition, the following specific
  137.    limitations are be mentioned:
  138.  
  139.    - The protocol is limited to networks whose longest path (the
  140.      network's diameter) is 15 hops.  The designers believe that the
  141.      basic protocol design is inappropriate for larger networks.  Note
  142.      that this statement of the limit assumes that a cost of 1 is used
  143.      for each network.  This is the way RIPng is normally configured.
  144.      If the system administrator chooses to use larger costs, the upper
  145.      bound of 15 can easily become a problem.
  146.  
  147.    - The protocol depends upon "counting to infinity" to resolve certain
  148.      unusual situations (see section 2.2 in [1]).  If the system of
  149.      networks has several hundred networks, and a routing loop was formed
  150.      involving all of them, the resolution of the loop would require
  151.      either much time (if the frequency of routing updates were limited)
  152.      or bandwidth (if updates were sent whenever changes were detected).
  153.      Such a loop would consume a large amount of network bandwidth
  154.      before the loop was corrected.  We believe that in realistic cases,
  155.      this will not be a problem except on slow lines.  Even then, the
  156.      problem will be fairly unusual, since various precautions are taken
  157.      that should prevent these problems in most cases.
  158.  
  159.    - This protocol uses fixed "metrics" to compare alternative routes.
  160.      It is not appropriate for situations where routes need to be chosen
  161.      based on real-time parameters such a measured delay, reliability,
  162.      or load.  The obvious extensions to allow metrics of this type are
  163.      likely to introduce instabilities of a sort that the protocol is
  164.      not designed to handle.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Malkin & Minnear            Standards Track                     [Page 3]
  171.  
  172. RFC 2080                     RIPng for IPv6                 January 1997
  173.  
  174.  
  175. 2. Protocol Specification
  176.  
  177.    RIPng is intended to allow routers to exchange information for
  178.    computing routes through an IPv6-based network.  RIPng is a distance
  179.    vector protocol, as described in [1].  RIPng should be implemented
  180.    only in routers; IPv6 provides other mechanisms for router discovery
  181.    [10].  Any router that uses RIPng is assumed to have interfaces to
  182.    one or more networks, otherwise it isn't really a router.  These are
  183.    referred to as its directly-connected networks.  The protocol relies
  184.    on access to certain information about each of these networks, the
  185.    most important of which is its metric.  The RIPng metric of a network
  186.    is an integer between 1 and 15, inclusive.  It is set in some manner
  187.    not specified in this protocol; however, given the maximum path limit
  188.    of 15, a value of 1 is usually used.  Implementations should allow
  189.    the system administrator to set the metric of each network.  In
  190.    addition to the metric, each network will have an IPv6 destination
  191.    address prefix and prefix length associated with it.  These are to be
  192.    set by the system administrator in a manner not specified in this
  193.    protocol.
  194.  
  195.    Each router that implements RIPng is assumed to have a routing table.
  196.    This table has one entry for every destination that is reachable
  197.    throughout the system operating RIPng.  Each entry contains at least
  198.    the following information:
  199.  
  200.    - The IPv6 prefix of the destination.
  201.  
  202.    - A metric, which represents the total cost of getting a datagram
  203.      from the router to that destination.  This metric is the sum of the
  204.      costs associated with the networks that would be traversed to get
  205.      to the destination.
  206.  
  207.    - The IPv6 address of the next router along the path to the
  208.      destination (i.e., the next hop).  If the destination is on one of
  209.      the directly-connected networks, this item is not needed.
  210.  
  211.    - A flag to indicate that information about the route has changed
  212.      recently.  This will be referred to as the "route change flag."
  213.  
  214.    - Various timers associated with the route.  See section 2.3 for more
  215.      details on timers.
  216.  
  217.    The entries for the directly-connected networks are set up by the
  218.    router using information gathered by means not specified in this
  219.    protocol.  The metric for a directly-connected network is set to the
  220.    cost of that network.  As mentioned, 1 is the usual cost.  In that
  221.    case, the RIPng metric reduces to a simple hop-count.  More complex
  222.    metrics may be used when it is desirable to show preference for some
  223.  
  224.  
  225.  
  226. Malkin & Minnear            Standards Track                     [Page 4]
  227.  
  228. RFC 2080                     RIPng for IPv6                 January 1997
  229.  
  230.  
  231.    networks over others (e.g., to indicate of differences in bandwidth
  232.    or reliability).
  233.  
  234.    Implementors may also choose to allow the system administrator to
  235.    enter additional routes.  These would most likely be routes to hosts
  236.    or networks outside the scope of the routing system.  They are
  237.    referred to as "static routes."  Entries for destinations other than
  238.    these initial ones are added and updated by the algorithms described
  239.    in the following sections.
  240.  
  241.    In order for the protocol to provide complete information on routing,
  242.    every router in the AS must participate in the protocol.  In cases
  243.    where multiple IGPs are in use, there must be at least one router
  244.    which can leak routing information between the protocols.
  245.  
  246. 2.1  Message Format
  247.  
  248.    RIPng is a UDP-based protocol.  Each router that uses RIPng has a
  249.    routing process that sends and receives datagrams on UDP port number
  250.    521, the RIPng port.  All communications intended for another
  251.    router's RIPng process are sent to the RIPng port.  All routing
  252.    update messages are sent from the RIPng port.  Unsolicited routing
  253.    update messages have both the source and destination port equal to
  254.    the RIPng port.  Those sent in response to a request are sent to the
  255.    port from which the request came.  Specific queries may be sent from
  256.    ports other than the RIPng port, but they must be directed to the
  257.    RIPng port on the target machine.
  258.  
  259.    The RIPng packet format is:
  260.  
  261.        0                   1                   2                   3
  262.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  263.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  264.       |  command (1)  |  version (1)  |       must be zero (2)        |
  265.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  266.       |                                                               |
  267.       ~                Route Table Entry 1 (20)                       ~
  268.       |                                                               |
  269.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  270.       |                                                               |
  271.       ~                         ...                                   ~
  272.       |                                                               |
  273.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  274.       |                                                               |
  275.       ~                Route Table Entry N (20)                       ~
  276.       |                                                               |
  277.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  278.  
  279.  
  280.  
  281.  
  282. Malkin & Minnear            Standards Track                     [Page 5]
  283.  
  284. RFC 2080                     RIPng for IPv6                 January 1997
  285.  
  286.  
  287.    where each Route Table Entry (RTE) has the following format:
  288.  
  289.        0                   1                   2                   3
  290.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  291.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  292.       |                                                               |
  293.       ~                        IPv6 prefix (16)                       ~
  294.       |                                                               |
  295.       +---------------------------------------------------------------+
  296.       |         route tag (2)         | prefix len (1)|  metric (1)   |
  297.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  298.  
  299.       The maximum number of RTEs is defined below.
  300.  
  301.    Field sizes are given in octets.  Unless otherwise specified, fields
  302.    contain binary integers, in network byte order, with the most-
  303.    significant octet first (big-endian).  Each tick mark represents one
  304.    bit.
  305.  
  306.    Every message contains a RIPng header which consists of a command and
  307.    a version number.  This document describes version 1 of the protocol
  308.    (see section 2.4).  The command field is used to specify the purpose
  309.    of this message.  The commands implemented in version 1 are:
  310.  
  311.    1 - request    A request for the responding system to send all or
  312.                   part of its routing table.
  313.  
  314.    2 - response   A message containing all or part of the sender's
  315.                   routing table.  This message may be sent in response
  316.                   to a request, or it may be an unsolicited routing
  317.                   update generated by the sender.
  318.  
  319.    For each of these message types, the remainder of the datagram
  320.    contains a list of RTEs.  Each RTE in this list contains a
  321.    destination prefix, the number of significant bits in the prefix, and
  322.    the cost to reach that destination (metric).
  323.  
  324.    The destination prefix is the usual 128-bit, IPv6 address prefix
  325.    stored as 16 octets in network byte order.
  326.  
  327.    The route tag field is an attribute assigned to a route which must be
  328.    preserved and readvertised with a route.  The intended use of the
  329.    route tag is to provide a method of separating "internal" RIPng
  330.    routes (routes for networks within the RIPng routing domain) from
  331.    "external" RIPng routes, which may have been imported from an EGP or
  332.    another IGP.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Malkin & Minnear            Standards Track                     [Page 6]
  339.  
  340. RFC 2080                     RIPng for IPv6                 January 1997
  341.  
  342.  
  343.    Routers supporting protocols other than RIPng should be configurable
  344.    to allow the route tag to be configured for routes imported from
  345.    different sources.  For example, routes imported from an EGP should
  346.    be able to have their route tag either set to an arbitrary value, or
  347.    at least to the number of the Autonomous System from which the routes
  348.    were learned.
  349.  
  350.    Other uses of the route tag are valid, as long as all routers in the
  351.    RIPng domain use it consistently.
  352.  
  353.    The prefix length field is the length in bits of the significant part
  354.    of the prefix (a value between 0 and 128 inclusive) starting from the
  355.    left of the prefix.
  356.  
  357.    The metric field contains a value between 1 and 15 inclusive,
  358.    specifying the current metric for the destination; or the value 16
  359.    (infinity), which indicates that the destination is not reachable.
  360.  
  361.    The maximum datagram size is limited by the MTU of the medium over
  362.    which the protocol is being used.  Since an unsolicited RIPng update
  363.    is never propagated across a router, there is no danger of an MTU
  364.    mismatch.  The determination of the number of RTEs which may be put
  365.    into a given message is a function of the medium's MTU, the number of
  366.    octets of header information preceeding the RIPng message, the size
  367.    of the RIPng header, and the size of an RTE.  The formula is:
  368.  
  369.                +-                                                   -+
  370.                | MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen |
  371.    #RTEs = INT | --------------------------------------------------- |
  372.                |                      RTE_size                       |
  373.                +-                                                   -+
  374.  
  375. 2.1.1  Next Hop
  376.  
  377.    RIPng provides the ability to specify the immediate next hop IPv6
  378.    address to which packets to a destination specified by a route table
  379.    entry (RTE) should be forwarded in much the same way as RIP-2 [2].
  380.    In RIP-2, each route table entry has a next hop field.  Including a
  381.    next hop field for each RTE in RIPng would nearly double the size of
  382.    the RTE.  Therefore, in RIPng, the next hop is specified by a special
  383.    RTE and applies to all of the address RTEs following the next hop RTE
  384.    until the end of the message or until another next hop RTE is
  385.    encountered.
  386.  
  387.    A next hop RTE is identified by a value of 0xFF in the metric field
  388.    of an RTE.  The prefix field specifies the IPv6 address of the next
  389.    hop.  The route tag and prefix length in the next hop RTE must be set
  390.    to zero on sending and ignored on receiption.
  391.  
  392.  
  393.  
  394. Malkin & Minnear            Standards Track                     [Page 7]
  395.  
  396. RFC 2080                     RIPng for IPv6                 January 1997
  397.  
  398.  
  399.    The next hop Route Table Entry (RTE) has the following format:
  400.  
  401.     0                   1                   2                   3
  402.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  403.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  404.    |                                                               |
  405.    ~                    IPv6 next hop address (16)                 ~
  406.    |                                                               |
  407.    +---------------------------------------------------------------+
  408.    |        must be zero (2)       |must be zero(1)|     0xFF      |
  409.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  410.  
  411.    Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of a next
  412.    hop RTE indicates that the next hop address should be the originator
  413.    of the RIPng advertisement.  An address specified as a next hop must
  414.    be a link-local address.
  415.  
  416.    The purpose of the next hop RTE is to eliminate packets being routed
  417.    through extra hops in the system.  It is particularly useful when
  418.    RIPng is not being run on all of the routers on a network.  Note that
  419.    next hop RTE is "advisory".  That is, if the provided information is
  420.    ignored, a possibly sub-optimal, but absolutely valid, route may be
  421.    taken.  If the received next hop address is not a link-local address,
  422.    it should be treated as 0:0:0:0:0:0:0:0.
  423.  
  424. 2.2  Addressing Considerations
  425.  
  426.    The distinction between network, subnet and host routes does not need
  427.    to be made for RIPng because an IPv6 address prefix is unambiguous.
  428.  
  429.    Any prefix with a prefix length of zero is used to designate a
  430.    default route.  It is suggested that the prefix 0:0:0:0:0:0:0:0 be
  431.    used when specifying the default route, though the prefix is
  432.    essentially ignored.  A default route is used when it is not
  433.    convenient to list every possible network in the RIPng updates, and
  434.    when one or more routers in the system are prepared to handle traffic
  435.    to the networks that are not explicitly listed.  These "default
  436.    routers" use the default route as a path for all datagrams for which
  437.    they have no explicit route.  The decision as to how a router becomes
  438.    a default router (i.e., how a default route entry is created) is left
  439.    to the implementor.  In general, the system administrator will be
  440.    provided with a way to specify which routers should create and
  441.    advertise default route entries.  If this mechanism is used, the
  442.    implementation should allow the network administrator to choose the
  443.    metric associated with the default route advertisement.  This will
  444.    make it possible to establish a precedence amoung multiple default
  445.    routers.  The default route entries are handled by RIPng in exactly
  446.    the same manner as any other destination prefix.  System
  447.  
  448.  
  449.  
  450. Malkin & Minnear            Standards Track                     [Page 8]
  451.  
  452. RFC 2080                     RIPng for IPv6                 January 1997
  453.  
  454.  
  455.    administrators should take care to make sure that default routes do
  456.    not propagate further than is intended.  Generally, each AS has its
  457.    own preferred default router.  Therefore, default routes should
  458.    generally not leave the boundary of an AS.  The mechanisms for
  459.    enforcing this restriction are not specified in this document.
  460.  
  461. 2.3  Timers
  462.  
  463.    This section describes all events that are triggered by timers.
  464.  
  465.    Every 30 seconds, the RIPng process is awakened to send an
  466.    unsolicited Response message, containing the complete routing table
  467.    (see section 2.6 on Split Horizon), to every neighboring router.
  468.    When there are many routers on a single network, there is a tendency
  469.    for them to synchronize with each other such that they all issue
  470.    updates at the same time.  This can happen whenever the 30 second
  471.    timer is affected by the processing load on the system.  It is
  472.    undesirable for the update messages to become synchronized, since it
  473.    can lead to unnecessary collisions on broadcast networks (see [13]
  474.    for more details).  Therefore, implementations are required to take
  475.    one of two precautions:
  476.  
  477.    - The 30-second updates are triggered by a clock whose rate is not
  478.      affected by system load or the time required to service the
  479.      previous update timer.
  480.  
  481.    - The 30-second timer is offset by a small random time (+/- 0 to 15
  482.      seconds) each time it is set.  The offset is derived from: 0.5 *
  483.      the update period (i.e. 30).
  484.  
  485.    There are two timers associated with each route, a "timeout" and a
  486.    "garbage-collection time."  Upon expiration of the timeout, the route
  487.    is no longer valid; however, it is retained in the routing table for
  488.    a short time so that neighbors can be notified that the route has
  489.    been dropped.  Upon expiration of the garbage-collection timer, the
  490.    route is finally removed from the routing table.
  491.  
  492.    The timeout is initialized when a route is established, and any time
  493.    an update message is received for the route.  If 180 seconds elapse
  494.    from the last time the timeout was initialized, the route is
  495.    considered to have expired, and the deletion process described below
  496.    begins for that route.
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Malkin & Minnear            Standards Track                     [Page 9]
  507.  
  508. RFC 2080                     RIPng for IPv6                 January 1997
  509.  
  510.  
  511.    Deletions can occur for one of two reasons: the timeout expires, or
  512.    the metric is set to 16 because of an update received from the
  513.    current router (see section 2.4.2 for a discussion of processing
  514.    updates from other routers).  In either case, the following events
  515.    happen:
  516.  
  517.    - The garbage-collection timer is set for 120 seconds.
  518.  
  519.    - The metric for the route is set to 16 (infinity).  This causes the
  520.      route to be removed from service.
  521.  
  522.    - The route change flag is to indicate that this entry has been
  523.      changed.
  524.  
  525.    - The output process is signalled to trigger a response.
  526.  
  527.    Until the garbage-collection timer expires, the route is included in
  528.    all updates sent by this router.  When the garbage-collection timer
  529.    expires, the route is deleted from the routing table.
  530.  
  531.    Should a new route to this network be established while the garbage-
  532.    collection timer is running, the new route will replace the one that
  533.    is about to be deleted.  In this case the garbage-collection timer
  534.    must be cleared.
  535.  
  536.    Triggered updates also use a small timer; however, this is best
  537.    described in section 2.5.1.
  538.  
  539. 2.4  Input Processing
  540.  
  541.    This section will describe the handling of datagrams received on the
  542.    RIPng port.  Processing will depend upon the value in the command
  543.    field.  Version 1 supports only two commands: Request and Response.
  544.  
  545. 2.4.1  Request Messages
  546.  
  547.    A Request is used to ask for a response containing all or part of a
  548.    router's routing table.  Normally, Requests are sent as multicasts,
  549.    from the RIPng port, by routers which have just come up and are
  550.    seeking to fill in their routing tables as quickly as possible.
  551.    However, there may be situations (e.g., router monitoring) where the
  552.    routing table of only a single router is needed.  In this case, the
  553.    Request should be sent directly to that router from a UDP port other
  554.    than the RIPng port.  If such a Request is received, the router
  555.    responds directly to the requestor's address and port with a globally
  556.    valid source address since the requestor may not reside on the
  557.    directly attached network.
  558.  
  559.  
  560.  
  561.  
  562. Malkin & Minnear            Standards Track                    [Page 10]
  563.  
  564. RFC 2080                     RIPng for IPv6                 January 1997
  565.  
  566.  
  567.    The Request is processed entry by entry.  If there are no entries, no
  568.    response is given.  There is one special case.  If there is exactly
  569.    one entry in the request, and it has a destination prefix of zero, a
  570.    prefix length of zero, and a metric of infinity (i.e., 16), then this
  571.    is a request to send the entire routing table.  In that case, a call
  572.    is made to the output process to send the routing table to the
  573.    requesting address/port.  Except for this special case, processing is
  574.    quite simple.  Examine the list of RTEs in the Request one by one.
  575.    For each entry, look up the destination in the router's routing
  576.    database and, if there is a route, put that route's metric in the
  577.    metric field of the RTE.  If there is no explicit route to the
  578.    specified destination, put infinity in the metric field.  Once all
  579.    the entries have been filled in, change the command from Request to
  580.    Response and send the datagram back to the requestor.
  581.  
  582.    Note that there is a difference in metric handling for specific and
  583.    whole-table requests.  If the request is for a complete routing
  584.    table, normal output processing is done, including Split Horizon (see
  585.    section 2.6 on Split Horizon).  If the request is for specific
  586.    entries, they are looked up in the routing table and the information
  587.    is returned as is; no Split Horizon processing is done.  The reason
  588.    for this distinction is the expectation that these requests are
  589.    likely to be used for different purposes.  When a router first comes
  590.    up, it multicasts a Request on every connected network asking for a
  591.    complete routing table.  It is assumed that these complete routing
  592.    tables are to be used to update the requestor's routing table.  For
  593.    this reason, Split Horizon must be done.  It is further assumed that
  594.    a Request for specific networks is made only by diagnostic software,
  595.    and is not used for routing.  In this case, the requester would want
  596.    to know the exact contents of the routing table and would not want
  597.    any information hidden or modified.
  598.  
  599. 2.4.2  Response Messages
  600.  
  601.    A Response can be received for one of several different reasons:
  602.  
  603.    - response to a specific query
  604.    - regular update (unsolicited response)
  605.    - triggered update caused by a route change
  606.  
  607.    Processing is the same no matter why the Response was generated.
  608.  
  609.    Because processing of a Response may update the router's routing
  610.    table, the Response must be checked carefully for validity.  The
  611.    Response must be ignored if it is not from the RIPng port.  The
  612.    datagram's IPv6 source address should be checked to see whether the
  613.    datagram is from a valid neighbor; the source of the datagram must be
  614.    a link-local address.  It is also worth checking to see whether the
  615.  
  616.  
  617.  
  618. Malkin & Minnear            Standards Track                    [Page 11]
  619.  
  620. RFC 2080                     RIPng for IPv6                 January 1997
  621.  
  622.  
  623.    response is from one of the router's own addresses.  Interfaces on
  624.    broadcast networks may receive copies of their own multicasts
  625.    immediately.  If a router processes its own output as new input,
  626.    confusion is likely, and such datagrams must be ignored.  As an
  627.    additional check, periodic advertisements must have their hop counts
  628.    set to 255, and inbound, multicast packets sent from the RIPng port
  629.    (i.e. periodic advertisement or triggered update packets) must be
  630.    examined to ensure that the hop count is 255.  This absolutely
  631.    guarantees that a packet is from a neighbor, because any intermediate
  632.    node would have decremented the hop count.  Queries and their
  633.    responses may still cross intermediate nodes and therefore do not
  634.    require the hop count test to be done.
  635.  
  636.    Once the datagram as a whole has been validated, process the RTEs in
  637.    the Response one by one.  Again, start by doing validation.
  638.    Incorrect metrics and other format errors usually indicate
  639.    misbehaving neighbors and should probably be brought to the
  640.    administrator's attention.  For example, if the metric is greater
  641.    than infinity, ignore the entry but log the event.  The basic
  642.    validation tests are:
  643.  
  644.    - is the destination prefix valid (e.g., not a multicast prefix and
  645.      not a link-local address)  A link-local address should never be
  646.      present in an RTE.
  647.    - is the prefix length valid (i.e., between 0 and 128, inclusive)
  648.    - is the metric valid (i.e., between 1 and 16, inclusive)
  649.  
  650.    If any check fails, ignore that entry and proceed to the next.
  651.    Again, logging the error is probably a good idea.
  652.  
  653.    Once the entry has been validated, update the metric by adding the
  654.    cost of the network on which the message arrived.  If the result is
  655.    greater than infinity, use infinity.  That is,
  656.  
  657.                   metric = MIN (metric + cost, infinity)
  658.  
  659.    Now, check to see whether there is already an explicit route for the
  660.    destination prefix.  If there is no such route, add this route to the
  661.    routing table, unless the metric is infinity (there is no point in
  662.    adding a route which unusable).  Adding a route to the routing table
  663.    consists of:
  664.  
  665.    - Setting the destination prefix and length to those in the RTE.
  666.  
  667.    - Setting the metric to the newly calculated metric (as described
  668.      above).
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Malkin & Minnear            Standards Track                    [Page 12]
  675.  
  676. RFC 2080                     RIPng for IPv6                 January 1997
  677.  
  678.  
  679.    - Set the next hop address to be the address of the router from which
  680.      the datagram came or the next hop address specified by a next hop
  681.      RTE.
  682.  
  683.    - Initialize the timeout for the route.  If the garbage-collection
  684.      timer is running for this route, stop it (see section 2.3 for a
  685.      discussion of the timers).
  686.  
  687.    - Set the route change flag.
  688.  
  689.    - Signal the output process to trigger an update (see section 2.5).
  690.  
  691.    If there is an existing route, compare the next hop address to the
  692.    address of the router from which the datagram came.  If this datagram
  693.    is from the same router as the existing route, reinitialize the
  694.    timeout.  Next, compare the metrics.  If the datagram is from the
  695.    same router as the existing route, and the new metric is different
  696.    than the old one; or, if the new metric is lower than the old one; do
  697.    the following actions:
  698.  
  699.    - Adopt the route from the datagram.  That is, put the new metric in,
  700.      and adjust the next hop address (if necessary).
  701.  
  702.    - Set the route change flag and signal the output process to trigger
  703.      an update.
  704.  
  705.    - If the new metric is infinity, start the deletion process
  706.      (described above); otherwise, re-initialize the timeout.
  707.  
  708.    If the new metric is infinity, the deletion process begins for the
  709.    route, which is no longer used for routing packets.  Note that the
  710.    deletion process is started only when the metric is first set to
  711.    infinity.  If the metric was already infinity, then a new deletion
  712.    process is not started.
  713.  
  714.    If the new metric is the same as the old one, it is simplest to do
  715.    nothing further (beyond reinitializing the timeout, as specified
  716.    above); but, there is a heuristic which could be applied.  Normally,
  717.    it is senseless to replace a route if the new route has the same
  718.    metric as the existing route; this would cause the route to bounce
  719.    back and forth, which would generate an intolerable number of
  720.    triggered updates.  However, if the existing route is showing signs
  721.    of timing out, it may be better to switch to an equally-good
  722.    alternative route immediately, rather than waiting for the timeout to
  723.    happen.  Therefore, if the new metric is the same as the old one,
  724.    examine the timeout for the existing route.  If it is at least
  725.    halfway to the expiration point, switch to the new route.  This
  726.    heuristic is optional, but highly recommended.
  727.  
  728.  
  729.  
  730. Malkin & Minnear            Standards Track                    [Page 13]
  731.  
  732. RFC 2080                     RIPng for IPv6                 January 1997
  733.  
  734.  
  735.    Any entry that fails these tests is ignored, as it is no better than
  736.    the current route.
  737.  
  738. 2.5  Output Processing
  739.  
  740.    This section describes the processing used to create response
  741.    messages that contain all or part of the routing table.  This
  742.    processing may be triggered in any of the following ways:
  743.  
  744.    - By input processing, when a Request is received.  In this case, the
  745.      Response is sent to only one destination (i.e. the unicast address
  746.      of the requestor).
  747.  
  748.    - By the regular routing update.  Every 30 seconds, a Response
  749.      containing the whole routing table is sent to every neighboring
  750.      router.
  751.  
  752.    - By triggered updates.  Whenever the metric for a route is changed,
  753.      an update is triggered.
  754.  
  755.    The special processing required for a Request is described in section
  756.    2.4.1.
  757.  
  758.    When a Response is to be sent to all neighbors (i.e., a regular or
  759.    triggered update), a Response message is multicast to the multicast
  760.    group FF02::9, the all-rip-routers multicast group, on all connected
  761.    networks that support broadcasting or are point-to-point links. RIPng
  762.    handles point-to-point links just like multicast links as
  763.    multicasting can be trivially provided on such links.  Thus, one
  764.    Response is prepared for each directly-connected network, and sent to
  765.    the all-rip-routers multicast group.  In most cases, this reaches all
  766.    neighboring routers.  However, there are some cases where this may
  767.    not be good enough. This may involve a network that is not a
  768.    broadcast network (e.g., the ARPANET), or a situation involving dumb
  769.    routers.  In such cases, it may be necessary to specify an actual
  770.    list of neighboring routers and send a datagram to each one
  771.    explicitly.  It is left to the implementor to determine whether such
  772.    a mechanism is needed, and to define how the list is specified.
  773.  
  774. 2.5.1  Triggered Updates
  775.  
  776.    Triggered updates require special handling for two reasons.  First,
  777.    experience shows that triggered updates can cause excessive loads on
  778.    networks with limited capacity or networks with many routers on them.
  779.    Therefore, the protocol requires that implementors include provisions
  780.    to limit the frequency of triggered updates.  After a triggered
  781.    update is sent, a timer should be set for a random interval between 1
  782.    and 5 seconds.  If other changes that would trigger updates occur
  783.  
  784.  
  785.  
  786. Malkin & Minnear            Standards Track                    [Page 14]
  787.  
  788. RFC 2080                     RIPng for IPv6                 January 1997
  789.  
  790.  
  791.    before the timer expires, a single update is triggered when the timer
  792.    expires.  The timer is then reset to another random value between 1
  793.    and 5 seconds.  Triggered updates may be suppressed if a regular
  794.    update is due by the time the triggered update would be sent.
  795.  
  796.    Second, triggered updates do not need to include the entire routing
  797.    table.  In principle, only those routes which have changed need to be
  798.    included.  Therefore messages generated as part of a triggered update
  799.    must include at least those routes that have their route change flag
  800.    set.  They may include additional routes, at the discretion of the
  801.    implementor; however, sending complete routing updates is strongly
  802.    discouraged.  When a triggered update is processed, messages should
  803.    be generated for every directly-connected network.  Split Horizon
  804.    processing is done when generating triggered updates as well as
  805.    normal updates (see section 2.6).  If, after Split Horizon processing
  806.    for a given network, a changed route will appear unchanged on that
  807.    network (e.g., it appears with an infinite metric), the route need
  808.    not be sent.  If no routes need be sent on that network, the update
  809.    may be omitted.  Once all of the triggered updates have been
  810.    generated, the route change flags should be cleared.
  811.  
  812.    If input processing is allowed while output is being generated,
  813.    appropriate interlocking must be done.  The route change flags should
  814.    not be changed as a result of processing input while a triggered
  815.    update message is being generated.
  816.  
  817.    The only difference between a triggered update and other update
  818.    messages is the possible omission of routes that have not changed.
  819.    The remaining mechanisms, described in the next section, must be
  820.    applied to all updates.
  821.  
  822. 2.5.2  Generating Response Messages
  823.  
  824.    This section describes how a Response message is generated for a
  825.    particular directly-connected network:
  826.  
  827.    The IPv6 source address must be a link-local address of the possible
  828.    addresses of the sending router's interface, except when replying to
  829.    a unicast Request Message from a port other than the RIPng port.  In
  830.    the latter case, the source address must be a globaly valid address.
  831.    In the former case, it is important to use a link-local address
  832.    because the source address is put into routing tables (as the next
  833.    hop) in the routers which receive this Response.  If an incorrect
  834.    source address is used, other routers may be unable to route
  835.    datagrams.  Sometimes routers are set up with multiple IPv6 addresses
  836.    on a single physical interface.  Normally, this means that several
  837.    logical IPv6 networks are being carried over one physical medium.  It
  838.    is possible that a router may have multiple link-local addresses for
  839.  
  840.  
  841.  
  842. Malkin & Minnear            Standards Track                    [Page 15]
  843.  
  844. RFC 2080                     RIPng for IPv6                 January 1997
  845.  
  846.  
  847.    a single interface. In this case, the router must only originate a
  848.    single Response message with a source address of the designated
  849.    link-local address for a given interface.  The choice of which link-
  850.    local address to use should only change when the current choice is no
  851.    longer valid.  This is necessary because nodes receiving Response
  852.    messages use the source address to identify the sender.  If multiple
  853.    packets from the same router contain different source addresses,
  854.    nodes will assume they come from different routers, leading to
  855.    undesirable behavior.
  856.  
  857.    Set the version number to the current version of RIPng.  The version
  858.    described in this document is version 1.  Set the command to
  859.    Response.  Set the bytes labeled "must be zero" to zero.  Start
  860.    filling in RTEs.  Recall that the maximum datagram size is limited by
  861.    the network's MTU.  When there is no more space in the datagram, send
  862.    the current Response and start a new one.
  863.  
  864.    To fill in the RTEs, examine each route in the routing table.  Routes
  865.    to link-local addresses must never be included in an RTE.  If a
  866.    triggered update is being generated, only entries whose route change
  867.    flags are set need be included.  If, after Split Horizon processing,
  868.    the route should not be included, skip it.  If the route is to be
  869.    included, then the destination prefix, prefix length, and metric are
  870.    put into the RTE.  The route tag is filled in as defined in section
  871.    2.1.  Routes must be included in the datagram even if their metrics
  872.    are infinite.
  873.  
  874. 2.6  Split Horizon
  875.  
  876.    Split Horizon is a algorithm for avoiding problems caused by
  877.    including routes in updates sent to the gateway from which they were
  878.    learned.  The basic split horizon algorithm omits routes learned from
  879.    one neighbor in updates sent to that neighbor.  In the case of a
  880.    broadcast network, all routes learned from any neighbor on that
  881.    network are omitted from updates sent on that network.
  882.  
  883.    Split Horizon with Poisoned Reverse (more simply, Poison Reverse)
  884.    does include such routes in updates, but sets their metrics to
  885.    infinity.  In effect, advertising the fact that there routes are not
  886.    reachable.  This is the preferred method of operation; however,
  887.    implementations should provide a per-interface control allowing no
  888.    horizoning, split horizoning, and poisoned reverse to be selected.
  889.  
  890.    For a theoretical discussion of Split Horizon and Poison Reverse, and
  891.    why they are needed, see section 2.1.1 of [1].
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Malkin & Minnear            Standards Track                    [Page 16]
  899.  
  900. RFC 2080                     RIPng for IPv6                 January 1997
  901.  
  902.  
  903. 3. Control Functions
  904.  
  905.    This section describes administrative controls.  These are not part
  906.    of the protocol per se; however, experience with existing networks
  907.    suggests that they are important.  Because they are not a necessary
  908.    part of the protocol, they are considered optional.  However, it is
  909.    strongly recommend that at least some of them be included in every
  910.    implementation.  These controls are intended primarily to allow RIPng
  911.    to be connected to networks whose routing may be unstable or subject
  912.    to errors.  Here are some examples:
  913.  
  914.    - It is sometimes desirable to restrict the routers from which
  915.      updates will be accepted, or to which updates will be sent.  This
  916.      is usually done for administrative, routing policy reasons.
  917.  
  918.    - A number of sites limit the set of networks that they allow in
  919.      Response messages.  Organization A may have a connection to
  920.      organization B that they use for direct communication.  For security
  921.      or performance reasons A may not be willing to give other
  922.      organizations access to that connection.  In such a case, A should
  923.      not include B's networks in updates that A sends to third parties.
  924.  
  925.    Here are some typical controls.  Note, however, that the RIPng
  926.    protocol does not require these or any other controls.
  927.  
  928.    - A neighbor list which allows the network administrator to be able
  929.      to define a list of neighbors for each router.  A router would
  930.      accept response messages only from routers on its list of
  931.      neighbors.  A similar list for target routers should also be
  932.      available to the administrator.  By default, no restrictions are
  933.      defined.
  934.  
  935.    - A filter for specific destinations would permit the network admin-
  936.      istrator to be able to specify a list of destination prefixes to
  937.      allow or disallow.  The list would be associated with a particular
  938.      interface in the incoming and/or outgoing directions.  Only allowed
  939.      networks would be mentioned in Response messages going out or
  940.      processed in Response messages coming in.  If a list of allowed
  941.      prefixes is specified, all other prefixes are disallowed.  If a list
  942.      of disallowed prefixes is specified, all other prefixes are
  943.      allowed.  By default, no filters are applied.
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Malkin & Minnear            Standards Track                    [Page 17]
  955.  
  956. RFC 2080                     RIPng for IPv6                 January 1997
  957.  
  958.  
  959. 4. Security Considerations
  960.  
  961.    Since RIPng runs over IPv6, RIPng relies on the IP Authentication
  962.    Header (see [11]) and the IP Encapsulating Security Payload (see
  963.    [12]) to ensure integrity and authentication/confidentiality of
  964.    routing exchanges.
  965.  
  966. References
  967.  
  968.    [1] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
  969.        University, June 1988.
  970.  
  971.    [2] Malkin, G., "RIP Version 2 - Carrying Additional Information",
  972.        RFC 1723, Xylogics, Inc., November, 1994.
  973.  
  974.    [3] Hinden, R., "IP Next Generation Overview",
  975.        Work in Progress.
  976.  
  977.    [4] Bellman, R., "Dynamic Programming", Princeton University
  978.        Press, Princeton, N.J., 1957.
  979.  
  980.    [5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-
  981.        Hall, Englewood Cliffs, N.J., 1987.
  982.  
  983.    [6] Braden, R., and J. Postel, "Requirements for Internet Gateways",
  984.        USC/Information Sciences Institute, STD 4, RFC 1009, June 1987.
  985.  
  986.    [7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
  987.        "Pup: An Internetwork Architecture", IEEE Transactions on Commu-
  988.        nications, April 1980.
  989.  
  990.    [8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
  991.        Princeton University Press, Princeton, N.J., 1962.
  992.  
  993.    [9] Xerox Corp., "Internet Transport Protocols", Xerox System Inte-
  994.        gration Standard XSIS 028112, December 1981.
  995.  
  996.    [10] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
  997.         for IP Version 6 (IPv6)", RFC 1970, August 1996.
  998.  
  999.    [11] Atkinson, R., "IP Authentication Header", RFC 1826
  1000.         Naval Research Laboratory, August 1995.
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Malkin & Minnear            Standards Track                    [Page 18]
  1011.  
  1012. RFC 2080                     RIPng for IPv6                 January 1997
  1013.  
  1014.  
  1015.    [12] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
  1016.         RFC 1827, Naval Research Laboratory, August 1995.
  1017.  
  1018.    [13] Floyd, S., and Jacobson, V., "The Synchronization of Periodic
  1019.         Routing Messages", Proceedings of ACM SIGCOMM '93, September
  1020.         1993.
  1021.  
  1022. Authors' Addresses
  1023.  
  1024.    Gary Scott Malkin
  1025.    Xylogics, Inc.
  1026.    53 Third Avenue
  1027.    Burlington, MA 01803
  1028.  
  1029.    Phone:  (617) 272-8140
  1030.    EMail:  gmalkin@Xylogics.COM
  1031.  
  1032.  
  1033.    Robert E. Minnear
  1034.    Ipsilon Networks, Inc.
  1035.    2191 E. Bayshore Road, Suite 100
  1036.    Palo Alto, CA 94303
  1037.  
  1038.    Phone:  (415) 846-4614
  1039.    EMail:  minnear@ipsilon.com
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Malkin & Minnear            Standards Track                    [Page 19]
  1067.  
  1068.