As per Relevance of the word triggered, we have this rfc below:
Network Working Group G.
Request for Comments: 2080
Category: Standards Track R.
Ipsilon
January 1997
RIPng for IPv
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document specifies a routing protocol for an IPv6 internet.
is based on protocols and algorithms currently in wide use in
IPv4 Internet
This specification represents the minimum change to the
Information Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723
[2], necessary for operation over IPv6 [3].
This document is a modified version of RFC 1058, written by
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
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.
This memo describes one protocol in a series of routing
based on the Bellman-Ford (or distance vector) algorithm.
algorithm has been used for routing computations in computer
since the early days of the ARPANET. The particular packet
and protocol described here are based on the program "routed,"
is included with the Berkeley distribution of Unix
In an international network, such as the Internet, it is
unlikely that a single routing protocol will used for the
network. Rather, the network will be organized as a collection
Autonomous Systems (AS), each of which will, in general,
administered by a single entity. Each AS will have its own
technology, which may differ among AS's. The routing protocol
within an AS is referred to as an Interior Gateway Protocol (IGP).
separate protocol, called an Exterior Gateway Protocol (EGP), is
to transfer routing information among the AS's. RIPng was
to work as an IGP in moderate-size AS's. It is not intended for
in more complex environments. For information on the context
which RIP version 1 (RIP-1) is expected to fit, see Braden and
[6].
RIPng is one of a class of algorithms known as Distance
algorithms. The earliest description of this class of
known to the author is in Ford and Fulkerson [8]. Because of this
they are sometimes known as Ford-Fulkerson algorithms. The
Bellman-Ford is also used, and derives from the fact that
formulation is based on Bellman's equation [4]. The presentation
this document is closely based on [5]. This document contains
protocol specification. For an introduction to the mathematics
routing algorithms, see [1]. The basic algorithms used by
protocol were used in computer routing as early as 1969 in
ARPANET. However, the specific ancestry of this protocol is
the Xerox network protocols. The PUP protocols [7] used the
Information Protocol to exchange routing information. A
updated version of this protocol was adopted for the Xerox
Systems (XNS) architecture, with the name Routing
Protocol [9]. Berkeley's routed is largely the same as the
Malkin & Minnear Standards Track [Page 2]
RFC 2080 RIPng for IPv6 January 1997
Information Protocol, with XNS addresses replaced by a more
address format capable of handling IPv4 and other types of address
and with routing updates limited to one every 30 seconds. Because
this similarity, the term Routing Information Protocol (or just RIP
is used to refer to both the XNS protocol and the protocol used
routed
1.1 Theoretical
An introduction to the theory and math behind Distance
protocols is provided in [1]. It has not been incorporated in
document for the sake of brevity
1.2 Limitations of the
This protocol does not solve every possible routing problem.
mentioned above, it is primarily intended for use as an IGP
networks of moderate size. In addition, the following
limitations are be mentioned
- The protocol is limited to networks whose longest path (
network's diameter) is 15 hops. The designers believe that
basic protocol design is inappropriate for larger networks.
that this statement of the limit assumes that a cost of 1 is
for each network. This is the way RIPng is normally configured
If the system administrator chooses to use larger costs, the
bound of 15 can easily become a problem
- The protocol depends upon "counting to infinity" to resolve
unusual situations (see section 2.2 in [1]). If the system
networks has several hundred networks, and a routing loop was
involving all of them, the resolution of the loop would
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
before the loop was corrected. We believe that in realistic cases
this will not be a problem except on slow lines. Even then,
problem will be fairly unusual, since various precautions are
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
based on real-time parameters such a measured delay, reliability
or load. The obvious extensions to allow metrics of this type
likely to introduce instabilities of a sort that the protocol
not designed to handle
Malkin & Minnear Standards Track [Page 3]
RFC 2080 RIPng for IPv6 January 1997
2. Protocol
RIPng is intended to allow routers to exchange information
computing routes through an IPv6-based network. RIPng is a
vector protocol, as described in [1]. RIPng should be
only in routers; IPv6 provides other mechanisms for router
[10]. Any router that uses RIPng is assumed to have interfaces
one or more networks, otherwise it isn't really a router. These
referred to as its directly-connected networks. The protocol
on access to certain information about each of these networks,
most important of which is its metric. The RIPng metric of a
is an integer between 1 and 15, inclusive. It is set in some
not specified in this protocol; however, given the maximum path
of 15, a value of 1 is usually used. Implementations should
the system administrator to set the metric of each network.
addition to the metric, each network will have an IPv6
address prefix and prefix length associated with it. These are to
set by the system administrator in a manner not specified in
protocol
Each router that implements RIPng is assumed to have a routing table
This table has one entry for every destination that is
throughout the system operating RIPng. Each entry contains at
the following information
- The IPv6 prefix of the destination
- A metric, which represents the total cost of getting a
from the router to that destination. This metric is the sum of
costs associated with the networks that would be traversed to
to the destination
- The IPv6 address of the next router along the path to
destination (i.e., the next hop). If the destination is on one
the directly-connected networks, this item is not needed
- A flag to indicate that information about the route has
recently. This will be referred to as the "route change flag."
- Various timers associated with the route. See section 2.3 for
details on timers
The entries for the directly-connected networks are set up by
router using information gathered by means not specified in
protocol. The metric for a directly-connected network is set to
cost of that network. As mentioned, 1 is the usual cost. In
case, the RIPng metric reduces to a simple hop-count. More
metrics may be used when it is desirable to show preference for
Malkin & Minnear Standards Track [Page 4]
RFC 2080 RIPng for IPv6 January 1997
networks over others (e.g., to indicate of differences in
or reliability).
Implementors may also choose to allow the system administrator
enter additional routes. These would most likely be routes to
or networks outside the scope of the routing system. They
referred to as "static routes." Entries for destinations other
these initial ones are added and updated by the algorithms
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
where multiple IGPs are in use, there must be at least one
which can leak routing information between the protocols
2.1 Message
RIPng is a UDP-based protocol. Each router that uses RIPng has
routing process that sends and receives datagrams on UDP port
521, the RIPng port. All communications intended for
router's RIPng process are sent to the RIPng port. All
update messages are sent from the RIPng port. Unsolicited
update messages have both the source and destination port equal
the RIPng port. Those sent in response to a request are sent to
port from which the request came. Specific queries may be sent
ports other than the RIPng port, but they must be directed to
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,
contain binary integers, in network byte order, with the most
significant octet first (big-endian). Each tick mark represents
bit
Every message contains a RIPng header which consists of a command
a version number. This document describes version 1 of the
(see section 2.4). The command field is used to specify the
of this message. The commands implemented in version 1 are
1 - request A request for the responding system to send all
part of its routing table
2 - response A message containing all or part of the sender'
routing table. This message may be sent in
to a request, or it may be an unsolicited
update generated by the sender
For each of these message types, the remainder of the
contains a list of RTEs. Each RTE in this list contains
destination prefix, the number of significant bits in the prefix,
the cost to reach that destination (metric).
The destination prefix is the usual 128-bit, IPv6 address
stored as 16 octets in network byte order
The route tag field is an attribute assigned to a route which must
preserved and readvertised with a route. The intended use of
route tag is to provide a method of separating "internal"
routes (routes for networks within the RIPng routing domain)
"external" RIPng routes, which may have been imported from an EGP
another IGP
Malkin & Minnear Standards Track [Page 6]
RFC 2080 RIPng for IPv6 January 1997
Routers supporting protocols other than RIPng should be
to allow the route tag to be configured for routes imported
different sources. For example, routes imported from an EGP
be able to have their route tag either set to an arbitrary value,
at least to the number of the Autonomous System from which the
were learned
Other uses of the route tag are valid, as long as all routers in
RIPng domain use it consistently
The prefix length field is the length in bits of the significant
of the prefix (a value between 0 and 128 inclusive) starting from
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
which the protocol is being used. Since an unsolicited RIPng
is never propagated across a router, there is no danger of an
mismatch. The determination of the number of RTEs which may be
into a given message is a function of the medium's MTU, the number
octets of header information preceeding the RIPng message, the
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
RIPng provides the ability to specify the immediate next hop IPv
address to which packets to a destination specified by a route
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
next hop field for each RTE in RIPng would nearly double the size
the RTE. Therefore, in RIPng, the next hop is specified by a
RTE and applies to all of the address RTEs following the next hop
until the end of the message or until another next hop RTE
encountered
A next hop RTE is identified by a value of 0xFF in the metric
of an RTE. The prefix field specifies the IPv6 address of the
hop. The route tag and prefix length in the next hop RTE must be
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
hop RTE indicates that the next hop address should be the
of the RIPng advertisement. An address specified as a next hop
be a link-local address
The purpose of the next hop RTE is to eliminate packets being
through extra hops in the system. It is particularly useful
RIPng is not being run on all of the routers on a network. Note
next hop RTE is "advisory". That is, if the provided information
ignored, a possibly sub-optimal, but absolutely valid, route may
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
The distinction between network, subnet and host routes does not
to be made for RIPng because an IPv6 address prefix is unambiguous
Any prefix with a prefix length of zero is used to designate
default route. It is suggested that the prefix 0:0:0:0:0:0:0:0
used when specifying the default route, though the prefix
essentially ignored. A default route is used when it is
convenient to list every possible network in the RIPng updates,
when one or more routers in the system are prepared to handle
to the networks that are not explicitly listed. These "
routers" use the default route as a path for all datagrams for
they have no explicit route. The decision as to how a router
a default router (i.e., how a default route entry is created) is
to the implementor. In general, the system administrator will
provided with a way to specify which routers should create
advertise default route entries. If this mechanism is used,
implementation should allow the network administrator to choose
metric associated with the default route advertisement. This
make it possible to establish a precedence amoung multiple
routers. The default route entries are handled by RIPng in
the same manner as any other destination prefix.
Malkin & Minnear Standards Track [Page 8]
RFC 2080 RIPng for IPv6 January 1997
administrators should take care to make sure that default routes
not propagate further than is intended. Generally, each AS has
own preferred default router. Therefore, default routes
generally not leave the boundary of an AS. The mechanisms
enforcing this restriction are not specified in this document
2.3
This section describes all events that are triggered by timers
Every 30 seconds, the RIPng process is awakened to send
unsolicited Response message, containing the complete routing
(see section 2.6 on Split Horizon), to every neighboring router
When there are many routers on a single network, there is a
for them to synchronize with each other such that they all
updates at the same time. This can happen whenever the 30
timer is affected by the processing load on the system. It
undesirable for the update messages to become synchronized, since
can lead to unnecessary collisions on broadcast networks (see [13]
for more details). Therefore, implementations are required to
one of two precautions
- The 30-second updates are triggered by a clock whose rate is
affected by system load or the time required to service
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
"garbage-collection time." Upon expiration of the timeout, the
is no longer valid; however, it is retained in the routing table
a short time so that neighbors can be notified that the route
been dropped. Upon expiration of the garbage-collection timer,
route is finally removed from the routing table
The timeout is initialized when a route is established, and any
an update message is received for the route. If 180 seconds
from the last time the timeout was initialized, the route
considered to have expired, and the deletion process described
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,
the metric is set to 16 because of an update received from
current router (see section 2.4.2 for a discussion of
updates from other routers). In either case, the following
happen
- The garbage-collection timer is set for 120 seconds
- The metric for the route is set to 16 (infinity). This causes
route to be removed from service
- The route change flag is to indicate that this entry has
changed
- The output process is signalled to trigger a response
Until the garbage-collection timer expires, the route is included
all updates sent by this router. When the garbage-collection
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
is about to be deleted. In this case the garbage-collection
must be cleared
Triggered updates also use a small timer; however, this is
described in section 2.5.1.
2.4 Input
This section will describe the handling of datagrams received on
RIPng port. Processing will depend upon the value in the
field. Version 1 supports only two commands: Request and Response
2.4.1 Request
A Request is used to ask for a response containing all or part of
router's routing table. Normally, Requests are sent as multicasts
from the RIPng port, by routers which have just come up and
seeking to fill in their routing tables as quickly as possible
However, there may be situations (e.g., router monitoring) where
routing table of only a single router is needed. In this case,
Request should be sent directly to that router from a UDP port
than the RIPng port. If such a Request is received, the
responds directly to the requestor's address and port with a
valid source address since the requestor may not reside on
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,
response is given. There is one special case. If there is
one entry in the request, and it has a destination prefix of zero,
prefix length of zero, and a metric of infinity (i.e., 16), then
is a request to send the entire routing table. In that case, a
is made to the output process to send the routing table to
requesting address/port. Except for this special case, processing
quite simple. Examine the list of RTEs in the Request one by one
For each entry, look up the destination in the router's
database and, if there is a route, put that route's metric in
metric field of the RTE. If there is no explicit route to
specified destination, put infinity in the metric field. Once
the entries have been filled in, change the command from Request
Response and send the datagram back to the requestor
Note that there is a difference in metric handling for specific
whole-table requests. If the request is for a complete
table, normal output processing is done, including Split Horizon (
section 2.6 on Split Horizon). If the request is for
entries, they are looked up in the routing table and the
is returned as is; no Split Horizon processing is done. The
for this distinction is the expectation that these requests
likely to be used for different purposes. When a router first
up, it multicasts a Request on every connected network asking for
complete routing table. It is assumed that these complete
tables are to be used to update the requestor's routing table.
this reason, Split Horizon must be done. It is further assumed
a Request for specific networks is made only by diagnostic software
and is not used for routing. In this case, the requester would
to know the exact contents of the routing table and would not
any information hidden or modified
2.4.2 Response
A Response can be received for one of several different reasons
- response to a specific
- regular update (unsolicited response
- triggered update caused by a route
Processing is the same no matter why the Response was generated
Because processing of a Response may update the router's
table, the Response must be checked carefully for validity.
Response must be ignored if it is not from the RIPng port.
datagram's IPv6 source address should be checked to see whether
datagram is from a valid neighbor; the source of the datagram must
a link-local address. It is also worth checking to see whether
Malkin & Minnear Standards Track [Page 11]
RFC 2080 RIPng for IPv6 January 1997
response is from one of the router's own addresses. Interfaces
broadcast networks may receive copies of their own
immediately. If a router processes its own output as new input
confusion is likely, and such datagrams must be ignored. As
additional check, periodic advertisements must have their hop
set to 255, and inbound, multicast packets sent from the RIPng
(i.e. periodic advertisement or triggered update packets) must
examined to ensure that the hop count is 255. This
guarantees that a packet is from a neighbor, because any
node would have decremented the hop count. Queries and
responses may still cross intermediate nodes and therefore do
require the hop count test to be done
Once the datagram as a whole has been validated, process the RTEs
the Response one by one. Again, start by doing validation
Incorrect metrics and other format errors usually
misbehaving neighbors and should probably be brought to
administrator's attention. For example, if the metric is
than infinity, ignore the entry but log the event. The
validation tests are
- is the destination prefix valid (e.g., not a multicast prefix
not a link-local address) A link-local address should never
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
cost of the network on which the message arrived. If the result
greater than infinity, use infinity. That is
metric = MIN (metric + cost, infinity
Now, check to see whether there is already an explicit route for
destination prefix. If there is no such route, add this route to
routing table, unless the metric is infinity (there is no point
adding a route which unusable). Adding a route to the routing
consists of
- Setting the destination prefix and length to those in the RTE
- Setting the metric to the newly calculated metric (as
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
the datagram came or the next hop address specified by a next
RTE
- Initialize the timeout for the route. If the garbage-
timer is running for this route, stop it (see section 2.3 for
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
address of the router from which the datagram came. If this
is from the same router as the existing route, reinitialize
timeout. Next, compare the metrics. If the datagram is from
same router as the existing route, and the new metric is
than the old one; or, if the new metric is lower than the old one;
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
an update
- If the new metric is infinity, start the deletion
(described above); otherwise, re-initialize the timeout
If the new metric is infinity, the deletion process begins for
route, which is no longer used for routing packets. Note that
deletion process is started only when the metric is first set
infinity. If the metric was already infinity, then a new
process is not started
If the new metric is the same as the old one, it is simplest to
nothing further (beyond reinitializing the timeout, as
above); but, there is a heuristic which could be applied. Normally
it is senseless to replace a route if the new route has the
metric as the existing route; this would cause the route to
back and forth, which would generate an intolerable number
triggered updates. However, if the existing route is showing
of timing out, it may be better to switch to an equally-
alternative route immediately, rather than waiting for the timeout
happen. Therefore, if the new metric is the same as the old one
examine the timeout for the existing route. If it is at
halfway to the expiration point, switch to the new route.
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
the current route
2.5 Output
This section describes the processing used to create
messages that contain all or part of the routing table.
processing may be triggered in any of the following ways
- By input processing, when a Request is received. In this case,
Response is sent to only one destination (i.e. the unicast
of the requestor).
- By the regular routing update. Every 30 seconds, a
containing the whole routing table is sent to every
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
2.4.1.
When a Response is to be sent to all neighbors (i.e., a regular
triggered update), a Response message is multicast to the
group FF02::9, the all-rip-routers multicast group, on all
networks that support broadcasting or are point-to-point links.
handles point-to-point links just like multicast links
multicasting can be trivially provided on such links. Thus,
Response is prepared for each directly-connected network, and sent
the all-rip-routers multicast group. In most cases, this reaches
neighboring routers. However, there are some cases where this
not be good enough. This may involve a network that is not
broadcast network (e.g., the ARPANET), or a situation involving
routers. In such cases, it may be necessary to specify an
list of neighboring routers and send a datagram to each
explicitly. It is left to the implementor to determine whether
a mechanism is needed, and to define how the list is specified
2.5.1 Triggered
Triggered updates require special handling for two reasons. First
experience shows that triggered updates can cause excessive loads
networks with limited capacity or networks with many routers on them
Therefore, the protocol requires that implementors include
to limit the frequency of triggered updates. After a
update is sent, a timer should be set for a random interval between 1
and 5 seconds. If other changes that would trigger updates
Malkin & Minnear Standards Track [Page 14]
RFC 2080 RIPng for IPv6 January 1997
before the timer expires, a single update is triggered when the
expires. The timer is then reset to another random value between 1
and 5 seconds. Triggered updates may be suppressed if a
update is due by the time the triggered update would be sent
Second, triggered updates do not need to include the entire
table. In principle, only those routes which have changed need to
included. Therefore messages generated as part of a triggered
must include at least those routes that have their route change
set. They may include additional routes, at the discretion of
implementor; however, sending complete routing updates is
discouraged. When a triggered update is processed, messages
be generated for every directly-connected network. Split
processing is done when generating triggered updates as well
normal updates (see section 2.6). If, after Split Horizon
for a given network, a changed route will appear unchanged on
network (e.g., it appears with an infinite metric), the route
not be sent. If no routes need be sent on that network, the
may be omitted. Once all of the triggered updates have
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
not be changed as a result of processing input while a
update message is being generated
The only difference between a triggered update and other
messages is the possible omission of routes that have not changed
The remaining mechanisms, described in the next section, must
applied to all updates
2.5.2 Generating Response
This section describes how a Response message is generated for
particular directly-connected network
The IPv6 source address must be a link-local address of the
addresses of the sending router's interface, except when replying
a unicast Request Message from a port other than the RIPng port.
the latter case, the source address must be a globaly valid address
In the former case, it is important to use a link-local
because the source address is put into routing tables (as the
hop) in the routers which receive this Response. If an
source address is used, other routers may be unable to
datagrams. Sometimes routers are set up with multiple IPv6
on a single physical interface. Normally, this means that
logical IPv6 networks are being carried over one physical medium.
is possible that a router may have multiple link-local addresses
Malkin & Minnear Standards Track [Page 15]
RFC 2080 RIPng for IPv6 January 1997
a single interface. In this case, the router must only originate
single Response message with a source address of the
link-local address for a given interface. The choice of which link
local address to use should only change when the current choice is
longer valid. This is necessary because nodes receiving
messages use the source address to identify the sender. If
packets from the same router contain different source addresses
nodes will assume they come from different routers, leading
undesirable behavior
Set the version number to the current version of RIPng. The
described in this document is version 1. Set the command
Response. Set the bytes labeled "must be zero" to zero.
filling in RTEs. Recall that the maximum datagram size is limited
the network's MTU. When there is no more space in the datagram,
the current Response and start a new one
To fill in the RTEs, examine each route in the routing table.
to link-local addresses must never be included in an RTE. If
triggered update is being generated, only entries whose route
flags are set need be included. If, after Split Horizon processing
the route should not be included, skip it. If the route is to
included, then the destination prefix, prefix length, and metric
put into the RTE. The route tag is filled in as defined in
2.1. Routes must be included in the datagram even if their
are infinite
2.6 Split
Split Horizon is a algorithm for avoiding problems caused
including routes in updates sent to the gateway from which they
learned. The basic split horizon algorithm omits routes learned
one neighbor in updates sent to that neighbor. In the case of
broadcast network, all routes learned from any neighbor on
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
infinity. In effect, advertising the fact that there routes are
reachable. This is the preferred method of operation; however
implementations should provide a per-interface control allowing
horizoning, split horizoning, and poisoned reverse to be selected
For a theoretical discussion of Split Horizon and Poison Reverse,
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
This section describes administrative controls. These are not
of the protocol per se; however, experience with existing
suggests that they are important. Because they are not a
part of the protocol, they are considered optional. However, it
strongly recommend that at least some of them be included in
implementation. These controls are intended primarily to allow
to be connected to networks whose routing may be unstable or
to errors. Here are some examples
- It is sometimes desirable to restrict the routers from
updates will be accepted, or to which updates will be sent.
is usually done for administrative, routing policy reasons
- A number of sites limit the set of networks that they allow
Response messages. Organization A may have a connection
organization B that they use for direct communication. For
or performance reasons A may not be willing to give
organizations access to that connection. In such a case, A
not include B's networks in updates that A sends to third parties
Here are some typical controls. Note, however, that the
protocol does not require these or any other controls
- A neighbor list which allows the network administrator to be
to define a list of neighbors for each router. A router
accept response messages only from routers on its list
neighbors. A similar list for target routers should also
available to the administrator. By default, no restrictions
defined
- A filter for specific destinations would permit the network admin
istrator to be able to specify a list of destination prefixes
allow or disallow. The list would be associated with a
interface in the incoming and/or outgoing directions. Only
networks would be mentioned in Response messages going out
processed in Response messages coming in. If a list of
prefixes is specified, all other prefixes are disallowed. If a
of disallowed prefixes is specified, all other prefixes
allowed. By default, no filters are applied
Malkin & Minnear Standards Track [Page 17]
RFC 2080 RIPng for IPv6 January 1997
4. Security
Since RIPng runs over IPv6, RIPng relies on the IP
Header (see [11]) and the IP Encapsulating Security Payload (
[12]) to ensure integrity and authentication/confidentiality
routing exchanges
[1] Hedrick, C., "Routing Information Protocol", RFC 1058,
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
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
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
Routing Messages", Proceedings of ACM SIGCOMM '93,
1993.
Authors'
Gary Scott
Xylogics, Inc
53 Third
Burlington, MA 01803
Phone: (617) 272-8140
EMail: gmalkin@Xylogics.
Robert E.
Ipsilon Networks, Inc
2191 E. Bayshore Road, Suite 100
Palo Alto, CA 94303
Phone: (415) 846-4614
EMail: minnear@ipsilon.
Malkin & Minnear Standards Track [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
