RFC1812 - Requirements for IP Version 4 Routers(7)
The time intervals (and derived variables) used in the following
algorithms are as follows:
Tu The Update Timer; the number of seconds between RIP updates.
This typically defaults to 30 seconds.
Rl The Route Lifetime, in seconds. This is the amount of time
that a route is presumed to be good, without requiring an
update. This typically defaults to 180 seconds.
Ul The Update Loss; the number of consecutive updates that have to
be lost or fail to mention a route before RIP deletes the
route. Ul is calculated to be (Rl/Tu)+1. The +1 is to
account for the fact that the first time the ifcounter is
decremented will be less than Tu seconds after it is
initialized. Typically, Ul will be 7: (180/30)+1.
In The value to set ifcounter to when a destination is newly
learned. This value is Ul-4, where the 4 is RIP's garbage
collection timer/30
The first algorithm is:
- Associated with each destination is a counter, called the
ifcounter below. Poison reverse is done for any route whose
destination's ifcounter is greater than zero.
- After a regular (not triggered or in response to a request)
update is sent, all the non-zero ifcounters are decremented by
one.
- When a route to a destination is created, its ifcounter is set
as follows:
- If the new route is superseding a valid route, and the old
route used a different (logical) output interface, then the
ifcounter is set to Ul.
- If the new route is superseding a stale route, and the old
route used a different (logical) output interface, then the
ifcounter is set to MAX(0, Ul - INT(seconds that the route
has been stale/Ut).
- If there was no previous route to the destination, the
ifcounter is set to In.
- Otherwise, the ifcounter is set to zero
- RIP also maintains a timer, called the resettimer below. Poison
reverse is done on all routes whenever resettimer has not
expired (regardless of the ifcounter values).
- When RIP is started, restarted, reset, or otherwise has its
routing table cleared, it sets the resettimer to go off in Rl
seconds.
The second algorithm is identical to the first except that:
- The rules which set the ifcounter to non-zero values are changed
to always set it to Rl/Tu, and
- The resettimer is eliminated.
Triggered updates: [ROUTE:3], page 15-16; page 29
Triggered updates (also called flash updates) are a mechanism for
immediately notifying a router's neighbors when the router adds or
deletes routes or changes their metrics. A router MUST send a
triggered update when routes are deleted or their metrics are
increased. A router MAY send a triggered update when routes are
added or their metrics decreased.
Since triggered updates can cause excessive routing overhead,
implementations MUST use the following mechanism to limit the
frequency of triggered updates:
(1) When a router sends a triggered update, it sets a timer to a
random time between one and five seconds in the future. The
router must not generate additional triggered updates before
this timer expires.
(2) If the router would generate a triggered update during this
interval it sets a flag indicating that a triggered update is
desired. The router also logs the desired triggered update.
(3) When the triggered update timer expires, the router checks the
triggered update flag. If the flag is set then the router
sends a single triggered update which includes all the
changes that were logged. The router then clears the flag
and, since a triggered update was sent, restarts this
algorithm.
(4) The flag is also cleared whenever a regular update is sent.
Triggered updates SHOULD include all routes that have changed
since the most recent regular (non-triggered) update. Triggered
updates MUST NOT include routes that have not changed since the
most recent regular update.
DISCUSSION
Sending all routes, whether they have changed recently or not, is
unacceptable in triggered updates because the tremendous size of
many Internet routing tables could otherwise result in
considerable bandwidth being wasted on triggered updates.
Use of UDP: [ROUTE:3], page 18-19.
RIP packets sent to an IP broadcast address SHOULD have their initial
TTL set to one.
Note that to comply with Section [6.1] of this memo, a router SHOULD
use UDP checksums in RIP packets that it originates, MUST discard RIP
packets received with invalid UDP checksums, but MUST NOT discard
received RIP packets simply because they do not contain UDP
checksums.
Addressing Considerations: [ROUTE:3], page 22
A RIP implementation SHOULD support host routes. If it does not, it
MUST (as described on page 27 of [ROUTE:3]) ignore host routes in
received updates. A router MAY log ignored hosts routes.
The special address 0.0.0.0 is used to describe a default route. A
default route is used as the route of last resort (i.e., when a route
to the specific net does not exist in the routing table). The router
MUST be able to create a RIP entry for the address 0.0.0.0.
Input Processing - Response: [ROUTE:3], page 26
When processing an update, the following validity checks MUST be
performed:
o The response MUST be from UDP port 520.
o The source address MUST be on a directly connected subnet (or on a
directly connected, non-subnetted network) to be considered valid.
o The source address MUST NOT be one of the router's addresses.
DISCUSSION
Some networks, media, and interfaces allow a sending node to
receive packets that it broadcasts. A router must not accept its
own packets as valid routing updates and process them. The last
requirement prevents a router from accepting its own routing
updates and processing them (on the assumption that they were sent
by some other router on the network).
An implementation MUST NOT replace an existing route if the metric
received is equal to the existing metric except in accordance with
the following heuristic.
An implementation MAY choose to implement the following heuristic to
deal with the above situation. Normally, it is useless to change the
route to a network from one router to another if both are advertised
at the same metric. However, the route being advertised by one of
the routers may be in the process of timing out. Instead of waiting
for the route to timeout, the new route can be used after a specified
amount of time has elapsed. If this heuristic is implemented, it
MUST wait at least halfway to the expiration point before the new
route is installed.
F.2.3 Specific Issues
RIP Shutdown
An implementation of RIP SHOULD provide for a graceful shutdown
using the following steps:
(1) Input processing is terminated,
(2) Four updates are generated at random intervals of between two
and four seconds, These updates contain all routes that were
previously announced, but with some metric changes. Routes
that were being announced at a metric of infinity should
continue to use this metric. Routes that had been announced
with a non-infinite metric should be announced with a metric
of 15 (infinity - 1).
DISCUSSION
The metric used for the above really ought to be 16 (infinity);
setting it to 15 is a kludge to avoid breaking certain old hosts
that wiretap the RIP protocol. Such a host will (erroneously)
abort a TCP connection if it tries to send a datagram on the
connection while the host has no route to the destination (even if
the period when the host has no route lasts only a few seconds
while RIP chooses an alternate path to the destination).
RIP Split Horizon and Static Routes
Split horizon SHOULD be applied to static routes by default. An
implementation SHOULD provide a way to specify, per static route,
that split horizon should not be applied to this route.
F.3 GATEWAY TO GATEWAY PROTOCOL - GGP
The Gateway to Gateway protocol is considered obsolete and SHOULD NOT
be implemented.
Acknowledgments
O that we now had here
But one ten thousand of those men in England
That do no work to-day!
What's he that wishes so?
My cousin Westmoreland? No, my fair cousin:
If we are mark'd to die, we are enow
To do our country loss; and if to live,
The fewer men, the greater share of honour.
God's will! I pray thee, wish not one man more.
By Jove, I am not covetous for gold,
Nor care I who doth feed upon my cost;
It yearns me not if men my garments wear;
Such outward things dwell not in my desires:
But if it be a sin to covet honour,
I am the most offending soul alive.
No, faith, my coz, wish not a man from England:
God's peace! I would not lose so great an honour
As one man more, methinks, would share from me
For the best hope I have. O, do not wish one more!
Rather proclaim it, Westmoreland, through my host,
That he which hath no stomach to this fight,
Let him depart; his passport shall be made
And crowns for convoy put into his purse:
We would not die in that man's company
That fears his fellowship to die with us.
This day is called the feast of Crispian:
He that outlives this day, and comes safe home,
Will stand a tip-toe when the day is named,
And rouse him at the name of Crispian.
He that shall live this day, and see old age,
Will yearly on the vigil feast his neighbours,
And say 'To-morrow is Saint Crispian:'
Then will he strip his sleeve and show his scars.
And say 'These wounds I had on Crispin's day.'
Old men forget: yet all shall be forgot,
But he'll remember with advantages
What feats he did that day: then shall our names.
Familiar in his mouth as household words
Harry the king, Bedford and Exeter,
Warwick and Talbot, Salisbury and Gloucester,
Be in their flowing cups freshly remember'd.
This story shall the good man teach his son;
And Crispin Crispian shall ne'er go by,
From this day to the ending of the world,
But we in it shall be remember'd;
We few, we happy few, we band of brothers;
For he to-day that sheds his blood with me
Shall be my brother; be he ne'er so vile,
This day shall gentle his condition:
And gentlemen in England now a-bed
Shall think themselves accursed they were not here,
And hold their manhoods cheap whiles any speaks
That fought with us upon Saint Crispin's day.
-- William Shakespeare
This memo is a product of the IETF's Router Requirements Working
Group. A memo such as this one is of necessity the work of many more
people than could be listed here. A wide variety of vendors, network
managers, and other experts from the Internet community graciously
contributed their time and wisdom to improve the quality of this
memo. The editor wishes to extend sincere thanks to all of them.
The current editor also wishes to single out and extend his heartfelt
gratitude and appreciation to the original editor of this document;
Philip Almquist. Without Philip's work, both as the original editor
and as the Chair of the working group, this document would not have
been produced. He also wishes to express deep and heartfelt
gratitude to the previous editor, Frank Kastenholz. Frank changed
the original document from a collection of information to a useful
description of IP technology - in his words, a "snapshot" of the
technology in 1991. One can only hope that this snapshot, of the
technology in 1994, is as clear.
Philip Almquist, Jeffrey Burgan, Frank Kastenholz, and Cathy
Wittbrodt each wrote major chapters of this memo. Others who made
major contributions to the document included Bill Barns, Steve
Deering, Kent England, Jim Forster, Martin Gross, Jeff Honig, Steve
Knowles, Yoni Malachi, Michael Reilly, and Walt Wimer.
Additional text came from Andy Malis, Paul Traina, Art Berggreen,
John Cavanaugh, Ross Callon, John Lekashman, Brian Lloyd, Gary
Malkin, Milo Medin, John Moy, Craig Partridge, Stephanie Price, Yakov
Rekhter, Steve Senum, Richard Smith, Frank Solensky, Rich Woundy, and
others who have been inadvertently overlooked.
Some of the text in this memo has been (shamelessly) plagiarized from
earlier documents, most notably RFC-1122 by Bob Braden and the Host
Requirements Working Group, and RFC-1009 by Bob Braden and Jon
Postel. The work of these earlier authors is gratefully
acknowledged.
Jim Forster was a co-chair of the Router Requirements Working Group
during its early meetings, and was instrumental in getting the group
off to a good start. Jon Postel, Bob Braden, and Walt Prue also
contributed to the success by providing a wealth of good advice
before the group's first meeting. Later on, Phill Gross, Vint Cerf,
and Noel Chiappa all provided valuable advice and support.
Mike St. Johns coordinated the Working Group's interactions with the
security community, and Frank Kastenholz coordinated the Working
Group's interactions with the network management area. Allison
Mankin and K.K. Ramakrishnan provided expertise on the issues of
congestion control and resource allocation.
Many more people than could possibly be listed or credited here
participated in the deliberations of the Router Requirements Working
Group, either through electronic mail or by attending meetings.
However, the efforts of Ross Callon and Vince Fuller in sorting out
the difficult issues of route choice and route leaking are especially
acknowledged.
The editor thanks his employer, Cisco Systems, for allowing him to
spend the time necessary to produce the 1994 snapshot.
Editor's Address
The address of the current editor of this document is
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
USA
Phone:+1 805-681-0115