doc: Add RFC documents

1 files changed, 1066 insertions, 0 deletions

diff --git a/doc/rfc/rfc2080.txt b/doc/rfc/rfc2080.txt
new file mode 100644
index 0000000..0105fa6
--- /dev/null
+++ b/doc/rfc/rfc2080.txt
@@ -0,0 +1,1066 @@
+
+
+
+
+
+
+Network Working Group                                          G. Malkin
+Request for Comments: 2080                                      Xylogics
+Category: Standards Track                                     R. Minnear
+                                                        Ipsilon Networks
+                                                            January 1997
+
+                             RIPng for IPv6
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies a routing protocol for an IPv6 internet.  It
+   is based on protocols and algorithms currently in wide use in the
+   IPv4 Internet.
+
+   This specification represents the minimum change to the Routing
+   Information Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723
+   [2], necessary for operation over IPv6 [3].
+
+Acknowledgements
+
+   This document is a modified version of RFC 1058, written by Chuck
+   Hedrick [1].  The modifications reflect RIP-2 and IPv6 enhancements,
+   but the original wording is his.
+
+   We'd like to thank Dennis Ferguson and Thomas Narten for their input.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   1.1   Theoretical Underpinnings  . . . . . . . . . . . . . . . . .  3
+   1.2   Limitations of the Protocol  . . . . . . . . . . . . . . . .  3
+   2.  Protocol Specification . . . . . . . . . . . . . . . . . . . .  4
+   2.1   Message Format . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.1.1   Next Hop . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.2   Addressing Considerations  . . . . . . . . . . . . . . . . .  8
+   2.3   Timers . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   2.4   Input Processing . . . . . . . . . . . . . . . . . . . . . . 10
+   2.4.1   Request Messages . . . . . . . . . . . . . . . . . . . . . 10
+   2.4.2   Response Messages  . . . . . . . . . . . . . . . . . . . . 11
+
+
+
+Malkin & Minnear            Standards Track                     [Page 1]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   2.5   Output Processing  . . . . . . . . . . . . . . . . . . . . . 14
+   2.5.1   Triggered Updates  . . . . . . . . . . . . . . . . . . . . 14
+   2.5.2   Generating Response Messages . . . . . . . . . . . . . . . 15
+   2.6   Split Horizon  . . . . . . . . . . . . . . . . . . . . . . . 16
+   3.  Control Functions  . . . . . . . . . . . . . . . . . . . . . . 17
+   4.  Security Considerations. . . . . . . . . . . . . . . . . . . . 18
+   References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
+
+1. Introduction
+
+   This memo describes one protocol in a series of routing protocols
+   based on the Bellman-Ford (or distance vector) algorithm.  This
+   algorithm has been used for routing computations in computer networks
+   since the early days of the ARPANET.  The particular packet formats
+   and protocol described here are based on the program "routed," which
+   is included with the Berkeley distribution of Unix.
+
+   In an international network, such as the Internet, it is very
+   unlikely that a single routing protocol will used for the entire
+   network.  Rather, the network will be organized as a collection of
+   Autonomous Systems (AS), each of which will, in general, be
+   administered by a single entity.  Each AS will have its own routing
+   technology, which may differ among AS's.  The routing protocol used
+   within an AS is referred to as an Interior Gateway Protocol (IGP).  A
+   separate protocol, called an Exterior Gateway Protocol (EGP), is used
+   to transfer routing information among the AS's.  RIPng was designed
+   to work as an IGP in moderate-size AS's.  It is not intended for use
+   in more complex environments.  For information on the context into
+   which RIP version 1 (RIP-1) is expected to fit, see Braden and Postel
+   [6].
+
+   RIPng is one of a class of algorithms known as Distance Vector
+   algorithms.  The earliest description of this class of algorithms
+   known to the author is in Ford and Fulkerson [8].  Because of this,
+   they are sometimes known as Ford-Fulkerson algorithms.  The term
+   Bellman-Ford is also used, and derives from the fact that the
+   formulation is based on Bellman's equation [4].  The presentation in
+   this document is closely based on [5].  This document contains a
+   protocol specification.  For an introduction to the mathematics of
+   routing algorithms, see [1].  The basic algorithms used by this
+   protocol were used in computer routing as early as 1969 in the
+   ARPANET.  However, the specific ancestry of this protocol is within
+   the Xerox network protocols.  The PUP protocols [7] used the Gateway
+   Information Protocol to exchange routing information.  A somewhat
+   updated version of this protocol was adopted for the Xerox Network
+   Systems (XNS) architecture, with the name Routing Information
+   Protocol [9].  Berkeley's routed is largely the same as the Routing
+
+
+
+Malkin & Minnear            Standards Track                     [Page 2]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   Information Protocol, with XNS addresses replaced by a more general
+   address format capable of handling IPv4 and other types of address,
+   and with routing updates limited to one every 30 seconds.  Because of
+   this similarity, the term Routing Information Protocol (or just RIP)
+   is used to refer to both the XNS protocol and the protocol used by
+   routed.
+
+1.1  Theoretical Underpinnings
+
+   An introduction to the theory and math behind Distance Vector
+   protocols is provided in [1].  It has not been incorporated in this
+   document for the sake of brevity.
+
+1.2  Limitations of the Protocol
+
+   This protocol does not solve every possible routing problem.  As
+   mentioned above, it is primarily intended for use as an IGP in
+   networks of moderate size.  In addition, the following specific
+   limitations are be mentioned:
+
+   - The protocol is limited to networks whose longest path (the
+     network's diameter) is 15 hops.  The designers believe that the
+     basic protocol design is inappropriate for larger networks.  Note
+     that this statement of the limit assumes that a cost of 1 is used
+     for each network.  This is the way RIPng is normally configured.
+     If the system administrator chooses to use larger costs, the upper
+     bound of 15 can easily become a problem.
+
+   - The protocol depends upon "counting to infinity" to resolve certain
+     unusual situations (see section 2.2 in [1]).  If the system of
+     networks has several hundred networks, and a routing loop was formed
+     involving all of them, the resolution of the loop would require
+     either much time (if the frequency of routing updates were limited)
+     or bandwidth (if updates were sent whenever changes were detected).
+     Such a loop would consume a large amount of network bandwidth
+     before the loop was corrected.  We believe that in realistic cases,
+     this will not be a problem except on slow lines.  Even then, the
+     problem will be fairly unusual, since various precautions are taken
+     that should prevent these problems in most cases.
+
+   - This protocol uses fixed "metrics" to compare alternative routes.
+     It is not appropriate for situations where routes need to be chosen
+     based on real-time parameters such a measured delay, reliability,
+     or load.  The obvious extensions to allow metrics of this type are
+     likely to introduce instabilities of a sort that the protocol is
+     not designed to handle.
+
+
+
+
+
+Malkin & Minnear            Standards Track                     [Page 3]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+2. Protocol Specification
+
+   RIPng is intended to allow routers to exchange information for
+   computing routes through an IPv6-based network.  RIPng is a distance
+   vector protocol, as described in [1].  RIPng should be implemented
+   only in routers; IPv6 provides other mechanisms for router discovery
+   [10].  Any router that uses RIPng is assumed to have interfaces to
+   one or more networks, otherwise it isn't really a router.  These are
+   referred to as its directly-connected networks.  The protocol relies
+   on access to certain information about each of these networks, the
+   most important of which is its metric.  The RIPng metric of a network
+   is an integer between 1 and 15, inclusive.  It is set in some manner
+   not specified in this protocol; however, given the maximum path limit
+   of 15, a value of 1 is usually used.  Implementations should allow
+   the system administrator to set the metric of each network.  In
+   addition to the metric, each network will have an IPv6 destination
+   address prefix and prefix length associated with it.  These are to be
+   set by the system administrator in a manner not specified in this
+   protocol.
+
+   Each router that implements RIPng is assumed to have a routing table.
+   This table has one entry for every destination that is reachable
+   throughout the system operating RIPng.  Each entry contains at least
+   the following information:
+
+   - The IPv6 prefix of the destination.
+
+   - A metric, which represents the total cost of getting a datagram
+     from the router to that destination.  This metric is the sum of the
+     costs associated with the networks that would be traversed to get
+     to the destination.
+
+   - The IPv6 address of the next router along the path to the
+     destination (i.e., the next hop).  If the destination is on one of
+     the directly-connected networks, this item is not needed.
+
+   - A flag to indicate that information about the route has changed
+     recently.  This will be referred to as the "route change flag."
+
+   - Various timers associated with the route.  See section 2.3 for more
+     details on timers.
+
+   The entries for the directly-connected networks are set up by the
+   router using information gathered by means not specified in this
+   protocol.  The metric for a directly-connected network is set to the
+   cost of that network.  As mentioned, 1 is the usual cost.  In that
+   case, the RIPng metric reduces to a simple hop-count.  More complex
+   metrics may be used when it is desirable to show preference for some
+
+
+
+Malkin & Minnear            Standards Track                     [Page 4]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   networks over others (e.g., to indicate of differences in bandwidth
+   or reliability).
+
+   Implementors may also choose to allow the system administrator to
+   enter additional routes.  These would most likely be routes to hosts
+   or networks outside the scope of the routing system.  They are
+   referred to as "static routes."  Entries for destinations other than
+   these initial ones are added and updated by the algorithms described
+   in the following sections.
+
+   In order for the protocol to provide complete information on routing,
+   every router in the AS must participate in the protocol.  In cases
+   where multiple IGPs are in use, there must be at least one router
+   which can leak routing information between the protocols.
+
+2.1  Message Format
+
+   RIPng is a UDP-based protocol.  Each router that uses RIPng has a
+   routing process that sends and receives datagrams on UDP port number
+   521, the RIPng port.  All communications intended for another
+   router's RIPng process are sent to the RIPng port.  All routing
+   update messages are sent from the RIPng port.  Unsolicited routing
+   update messages have both the source and destination port equal to
+   the RIPng port.  Those sent in response to a request are sent to the
+   port from which the request came.  Specific queries may be sent from
+   ports other than the RIPng port, but they must be directed to the
+   RIPng port on the target machine.
+
+   The RIPng packet format is:
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  command (1)  |  version (1)  |       must be zero (2)        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                Route Table Entry 1 (20)                       ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                         ...                                   ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                Route Table Entry N (20)                       ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Malkin & Minnear            Standards Track                     [Page 5]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   where each Route Table Entry (RTE) has the following format:
+
+       0                   1                   2                   3
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                        IPv6 prefix (16)                       ~
+      |                                                               |
+      +---------------------------------------------------------------+
+      |         route tag (2)         | prefix len (1)|  metric (1)   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The maximum number of RTEs is defined below.
+
+   Field sizes are given in octets.  Unless otherwise specified, fields
+   contain binary integers, in network byte order, with the most-
+   significant octet first (big-endian).  Each tick mark represents one
+   bit.
+
+   Every message contains a RIPng header which consists of a command and
+   a version number.  This document describes version 1 of the protocol
+   (see section 2.4).  The command field is used to specify the purpose
+   of this message.  The commands implemented in version 1 are:
+
+   1 - request    A request for the responding system to send all or
+                  part of its routing table.
+
+   2 - response   A message containing all or part of the sender's
+                  routing table.  This message may be sent in response
+                  to a request, or it may be an unsolicited routing
+                  update generated by the sender.
+
+   For each of these message types, the remainder of the datagram
+   contains a list of RTEs.  Each RTE in this list contains a
+   destination prefix, the number of significant bits in the prefix, and
+   the cost to reach that destination (metric).
+
+   The destination prefix is the usual 128-bit, IPv6 address prefix
+   stored as 16 octets in network byte order.
+
+   The route tag field is an attribute assigned to a route which must be
+   preserved and readvertised with a route.  The intended use of the
+   route tag is to provide a method of separating "internal" RIPng
+   routes (routes for networks within the RIPng routing domain) from
+   "external" RIPng routes, which may have been imported from an EGP or
+   another IGP.
+
+
+
+
+
+Malkin & Minnear            Standards Track                     [Page 6]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   Routers supporting protocols other than RIPng should be configurable
+   to allow the route tag to be configured for routes imported from
+   different sources.  For example, routes imported from an EGP should
+   be able to have their route tag either set to an arbitrary value, or
+   at least to the number of the Autonomous System from which the routes
+   were learned.
+
+   Other uses of the route tag are valid, as long as all routers in the
+   RIPng domain use it consistently.
+
+   The prefix length field is the length in bits of the significant part
+   of the prefix (a value between 0 and 128 inclusive) starting from the
+   left of the prefix.
+
+   The metric field contains a value between 1 and 15 inclusive,
+   specifying the current metric for the destination; or the value 16
+   (infinity), which indicates that the destination is not reachable.
+
+   The maximum datagram size is limited by the MTU of the medium over
+   which the protocol is being used.  Since an unsolicited RIPng update
+   is never propagated across a router, there is no danger of an MTU
+   mismatch.  The determination of the number of RTEs which may be put
+   into a given message is a function of the medium's MTU, the number of
+   octets of header information preceeding the RIPng message, the size
+   of the RIPng header, and the size of an RTE.  The formula is:
+
+               +-                                                   -+
+               | MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen |
+   #RTEs = INT | --------------------------------------------------- |
+               |                      RTE_size                       |
+               +-                                                   -+
+
+2.1.1  Next Hop
+
+   RIPng provides the ability to specify the immediate next hop IPv6
+   address to which packets to a destination specified by a route table
+   entry (RTE) should be forwarded in much the same way as RIP-2 [2].
+   In RIP-2, each route table entry has a next hop field.  Including a
+   next hop field for each RTE in RIPng would nearly double the size of
+   the RTE.  Therefore, in RIPng, the next hop is specified by a special
+   RTE and applies to all of the address RTEs following the next hop RTE
+   until the end of the message or until another next hop RTE is
+   encountered.
+
+   A next hop RTE is identified by a value of 0xFF in the metric field
+   of an RTE.  The prefix field specifies the IPv6 address of the next
+   hop.  The route tag and prefix length in the next hop RTE must be set
+   to zero on sending and ignored on receiption.
+
+
+
+Malkin & Minnear            Standards Track                     [Page 7]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   The next hop Route Table Entry (RTE) has the following format:
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                    IPv6 next hop address (16)                 ~
+   |                                                               |
+   +---------------------------------------------------------------+
+   |        must be zero (2)       |must be zero(1)|     0xFF      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of a next
+   hop RTE indicates that the next hop address should be the originator
+   of the RIPng advertisement.  An address specified as a next hop must
+   be a link-local address.
+
+   The purpose of the next hop RTE is to eliminate packets being routed
+   through extra hops in the system.  It is particularly useful when
+   RIPng is not being run on all of the routers on a network.  Note that
+   next hop RTE is "advisory".  That is, if the provided information is
+   ignored, a possibly sub-optimal, but absolutely valid, route may be
+   taken.  If the received next hop address is not a link-local address,
+   it should be treated as 0:0:0:0:0:0:0:0.
+
+2.2  Addressing Considerations
+
+   The distinction between network, subnet and host routes does not need
+   to be made for RIPng because an IPv6 address prefix is unambiguous.
+
+   Any prefix with a prefix length of zero is used to designate a
+   default route.  It is suggested that the prefix 0:0:0:0:0:0:0:0 be
+   used when specifying the default route, though the prefix is
+   essentially ignored.  A default route is used when it is not
+   convenient to list every possible network in the RIPng updates, and
+   when one or more routers in the system are prepared to handle traffic
+   to the networks that are not explicitly listed.  These "default
+   routers" use the default route as a path for all datagrams for which
+   they have no explicit route.  The decision as to how a router becomes
+   a default router (i.e., how a default route entry is created) is left
+   to the implementor.  In general, the system administrator will be
+   provided with a way to specify which routers should create and
+   advertise default route entries.  If this mechanism is used, the
+   implementation should allow the network administrator to choose the
+   metric associated with the default route advertisement.  This will
+   make it possible to establish a precedence amoung multiple default
+   routers.  The default route entries are handled by RIPng in exactly
+   the same manner as any other destination prefix.  System
+
+
+
+Malkin & Minnear            Standards Track                     [Page 8]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   administrators should take care to make sure that default routes do
+   not propagate further than is intended.  Generally, each AS has its
+   own preferred default router.  Therefore, default routes should
+   generally not leave the boundary of an AS.  The mechanisms for
+   enforcing this restriction are not specified in this document.
+
+2.3  Timers
+
+   This section describes all events that are triggered by timers.
+
+   Every 30 seconds, the RIPng process is awakened to send an
+   unsolicited Response message, containing the complete routing table
+   (see section 2.6 on Split Horizon), to every neighboring router.
+   When there are many routers on a single network, there is a tendency
+   for them to synchronize with each other such that they all issue
+   updates at the same time.  This can happen whenever the 30 second
+   timer is affected by the processing load on the system.  It is
+   undesirable for the update messages to become synchronized, since it
+   can lead to unnecessary collisions on broadcast networks (see [13]
+   for more details).  Therefore, implementations are required to take
+   one of two precautions:
+
+   - The 30-second updates are triggered by a clock whose rate is not
+     affected by system load or the time required to service the
+     previous update timer.
+
+   - The 30-second timer is offset by a small random time (+/- 0 to 15
+     seconds) each time it is set.  The offset is derived from: 0.5 *
+     the update period (i.e. 30).
+
+   There are two timers associated with each route, a "timeout" and a
+   "garbage-collection time."  Upon expiration of the timeout, the route
+   is no longer valid; however, it is retained in the routing table for
+   a short time so that neighbors can be notified that the route has
+   been dropped.  Upon expiration of the garbage-collection timer, the
+   route is finally removed from the routing table.
+
+   The timeout is initialized when a route is established, and any time
+   an update message is received for the route.  If 180 seconds elapse
+   from the last time the timeout was initialized, the route is
+   considered to have expired, and the deletion process described below
+   begins for that route.
+
+
+
+
+
+
+
+
+
+Malkin & Minnear            Standards Track                     [Page 9]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   Deletions can occur for one of two reasons: the timeout expires, or
+   the metric is set to 16 because of an update received from the
+   current router (see section 2.4.2 for a discussion of processing
+   updates from other routers).  In either case, the following events
+   happen:
+
+   - The garbage-collection timer is set for 120 seconds.
+
+   - The metric for the route is set to 16 (infinity).  This causes the
+     route to be removed from service.
+
+   - The route change flag is to indicate that this entry has been
+     changed.
+
+   - The output process is signalled to trigger a response.
+
+   Until the garbage-collection timer expires, the route is included in
+   all updates sent by this router.  When the garbage-collection timer
+   expires, the route is deleted from the routing table.
+
+   Should a new route to this network be established while the garbage-
+   collection timer is running, the new route will replace the one that
+   is about to be deleted.  In this case the garbage-collection timer
+   must be cleared.
+
+   Triggered updates also use a small timer; however, this is best
+   described in section 2.5.1.
+
+2.4  Input Processing
+
+   This section will describe the handling of datagrams received on the
+   RIPng port.  Processing will depend upon the value in the command
+   field.  Version 1 supports only two commands: Request and Response.
+
+2.4.1  Request Messages
+
+   A Request is used to ask for a response containing all or part of a
+   router's routing table.  Normally, Requests are sent as multicasts,
+   from the RIPng port, by routers which have just come up and are
+   seeking to fill in their routing tables as quickly as possible.
+   However, there may be situations (e.g., router monitoring) where the
+   routing table of only a single router is needed.  In this case, the
+   Request should be sent directly to that router from a UDP port other
+   than the RIPng port.  If such a Request is received, the router
+   responds directly to the requestor's address and port with a globally
+   valid source address since the requestor may not reside on the
+   directly attached network.
+
+
+
+
+Malkin & Minnear            Standards Track                    [Page 10]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   The Request is processed entry by entry.  If there are no entries, no
+   response is given.  There is one special case.  If there is exactly
+   one entry in the request, and it has a destination prefix of zero, a
+   prefix length of zero, and a metric of infinity (i.e., 16), then this
+   is a request to send the entire routing table.  In that case, a call
+   is made to the output process to send the routing table to the
+   requesting address/port.  Except for this special case, processing is
+   quite simple.  Examine the list of RTEs in the Request one by one.
+   For each entry, look up the destination in the router's routing
+   database and, if there is a route, put that route's metric in the
+   metric field of the RTE.  If there is no explicit route to the
+   specified destination, put infinity in the metric field.  Once all
+   the entries have been filled in, change the command from Request to
+   Response and send the datagram back to the requestor.
+
+   Note that there is a difference in metric handling for specific and
+   whole-table requests.  If the request is for a complete routing
+   table, normal output processing is done, including Split Horizon (see
+   section 2.6 on Split Horizon).  If the request is for specific
+   entries, they are looked up in the routing table and the information
+   is returned as is; no Split Horizon processing is done.  The reason
+   for this distinction is the expectation that these requests are
+   likely to be used for different purposes.  When a router first comes
+   up, it multicasts a Request on every connected network asking for a
+   complete routing table.  It is assumed that these complete routing
+   tables are to be used to update the requestor's routing table.  For
+   this reason, Split Horizon must be done.  It is further assumed that
+   a Request for specific networks is made only by diagnostic software,
+   and is not used for routing.  In this case, the requester would want
+   to know the exact contents of the routing table and would not want
+   any information hidden or modified.
+
+2.4.2  Response Messages
+
+   A Response can be received for one of several different reasons:
+
+   - response to a specific query
+   - regular update (unsolicited response)
+   - triggered update caused by a route change
+
+   Processing is the same no matter why the Response was generated.
+
+   Because processing of a Response may update the router's routing
+   table, the Response must be checked carefully for validity.  The
+   Response must be ignored if it is not from the RIPng port.  The
+   datagram's IPv6 source address should be checked to see whether the
+   datagram is from a valid neighbor; the source of the datagram must be
+   a link-local address.  It is also worth checking to see whether the
+
+
+
+Malkin & Minnear            Standards Track                    [Page 11]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   response is from one of the router's own addresses.  Interfaces on
+   broadcast networks may receive copies of their own multicasts
+   immediately.  If a router processes its own output as new input,
+   confusion is likely, and such datagrams must be ignored.  As an
+   additional check, periodic advertisements must have their hop counts
+   set to 255, and inbound, multicast packets sent from the RIPng port
+   (i.e. periodic advertisement or triggered update packets) must be
+   examined to ensure that the hop count is 255.  This absolutely
+   guarantees that a packet is from a neighbor, because any intermediate
+   node would have decremented the hop count.  Queries and their
+   responses may still cross intermediate nodes and therefore do not
+   require the hop count test to be done.
+
+   Once the datagram as a whole has been validated, process the RTEs in
+   the Response one by one.  Again, start by doing validation.
+   Incorrect metrics and other format errors usually indicate
+   misbehaving neighbors and should probably be brought to the
+   administrator's attention.  For example, if the metric is greater
+   than infinity, ignore the entry but log the event.  The basic
+   validation tests are:
+
+   - is the destination prefix valid (e.g., not a multicast prefix and
+     not a link-local address)  A link-local address should never be
+     present in an RTE.
+   - is the prefix length valid (i.e., between 0 and 128, inclusive)
+   - is the metric valid (i.e., between 1 and 16, inclusive)
+
+   If any check fails, ignore that entry and proceed to the next.
+   Again, logging the error is probably a good idea.
+
+   Once the entry has been validated, update the metric by adding the
+   cost of the network on which the message arrived.  If the result is
+   greater than infinity, use infinity.  That is,
+
+                  metric = MIN (metric + cost, infinity)
+
+   Now, check to see whether there is already an explicit route for the
+   destination prefix.  If there is no such route, add this route to the
+   routing table, unless the metric is infinity (there is no point in
+   adding a route which unusable).  Adding a route to the routing table
+   consists of:
+
+   - Setting the destination prefix and length to those in the RTE.
+
+   - Setting the metric to the newly calculated metric (as described
+     above).
+
+
+
+
+
+Malkin & Minnear            Standards Track                    [Page 12]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   - Set the next hop address to be the address of the router from which
+     the datagram came or the next hop address specified by a next hop
+     RTE.
+
+   - Initialize the timeout for the route.  If the garbage-collection
+     timer is running for this route, stop it (see section 2.3 for a
+     discussion of the timers).
+
+   - Set the route change flag.
+
+   - Signal the output process to trigger an update (see section 2.5).
+
+   If there is an existing route, compare the next hop address to the
+   address of the router from which the datagram came.  If this datagram
+   is from the same router as the existing route, reinitialize the
+   timeout.  Next, compare the metrics.  If the datagram is from the
+   same router as the existing route, and the new metric is different
+   than the old one; or, if the new metric is lower than the old one; do
+   the following actions:
+
+   - Adopt the route from the datagram.  That is, put the new metric in,
+     and adjust the next hop address (if necessary).
+
+   - Set the route change flag and signal the output process to trigger
+     an update.
+
+   - If the new metric is infinity, start the deletion process
+     (described above); otherwise, re-initialize the timeout.
+
+   If the new metric is infinity, the deletion process begins for the
+   route, which is no longer used for routing packets.  Note that the
+   deletion process is started only when the metric is first set to
+   infinity.  If the metric was already infinity, then a new deletion
+   process is not started.
+
+   If the new metric is the same as the old one, it is simplest to do
+   nothing further (beyond reinitializing the timeout, as specified
+   above); but, there is a heuristic which could be applied.  Normally,
+   it is senseless to replace a route if the new route has the same
+   metric as the existing route; this would cause the route to bounce
+   back and forth, which would generate an intolerable number of
+   triggered updates.  However, if the existing route is showing signs
+   of timing out, it may be better to switch to an equally-good
+   alternative route immediately, rather than waiting for the timeout to
+   happen.  Therefore, if the new metric is the same as the old one,
+   examine the timeout for the existing route.  If it is at least
+   halfway to the expiration point, switch to the new route.  This
+   heuristic is optional, but highly recommended.
+
+
+
+Malkin & Minnear            Standards Track                    [Page 13]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   Any entry that fails these tests is ignored, as it is no better than
+   the current route.
+
+2.5  Output Processing
+
+   This section describes the processing used to create response
+   messages that contain all or part of the routing table.  This
+   processing may be triggered in any of the following ways:
+
+   - By input processing, when a Request is received.  In this case, the
+     Response is sent to only one destination (i.e. the unicast address
+     of the requestor).
+
+   - By the regular routing update.  Every 30 seconds, a Response
+     containing the whole routing table is sent to every neighboring
+     router.
+
+   - By triggered updates.  Whenever the metric for a route is changed,
+     an update is triggered.
+
+   The special processing required for a Request is described in section
+   2.4.1.
+
+   When a Response is to be sent to all neighbors (i.e., a regular or
+   triggered update), a Response message is multicast to the multicast
+   group FF02::9, the all-rip-routers multicast group, on all connected
+   networks that support broadcasting or are point-to-point links. RIPng
+   handles point-to-point links just like multicast links as
+   multicasting can be trivially provided on such links.  Thus, one
+   Response is prepared for each directly-connected network, and sent to
+   the all-rip-routers multicast group.  In most cases, this reaches all
+   neighboring routers.  However, there are some cases where this may
+   not be good enough. This may involve a network that is not a
+   broadcast network (e.g., the ARPANET), or a situation involving dumb
+   routers.  In such cases, it may be necessary to specify an actual
+   list of neighboring routers and send a datagram to each one
+   explicitly.  It is left to the implementor to determine whether such
+   a mechanism is needed, and to define how the list is specified.
+
+2.5.1  Triggered Updates
+
+   Triggered updates require special handling for two reasons.  First,
+   experience shows that triggered updates can cause excessive loads on
+   networks with limited capacity or networks with many routers on them.
+   Therefore, the protocol requires that implementors include provisions
+   to limit the frequency of triggered updates.  After a triggered
+   update is sent, a timer should be set for a random interval between 1
+   and 5 seconds.  If other changes that would trigger updates occur
+
+
+
+Malkin & Minnear            Standards Track                    [Page 14]
+
+RFC 2080                     RIPng for IPv6                 January 1997
+
+
+   before the timer expires, a single update is triggered when the timer
+   expires.  The timer is then reset to another random value between 1
+   and 5 seconds.  Triggered updates may be suppressed if a regular
+   update is due by the time the triggered update would be sent.
+
+   Second, triggered updates do not need to include the entire routing
+   table.  In principle, only those routes which have changed need to be
+   included.  Therefore messages generated as part of a triggered update
+   must include at least those routes that have their route change flag
+   set.  They may include additional routes, at the discretion of the
+   implementor; however, sending complete routing updates is strongly
+   discouraged.  When a triggered update is processed, messages should
+   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:  (617) 272-8140
+   EMail:  gmalkin@Xylogics.COM
+
+
+   Robert E. Minnear
+   Ipsilon Networks, Inc.
+   2191 E. Bayshore Road, Suite 100
+   Palo Alto, CA 94303
+
+   Phone:  (415) 846-4614
+   EMail:  minnear@ipsilon.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin & Minnear            Standards Track                    [Page 19]
+