A RIP a XEROX PARC által kifejlesztett GWINFO nevû protokollból származik, melyet az XNS-be RIP néven integráltak. Az Internethez 1982-ben kapcsolódik, amikor a BSD UNIX egy „routed" elnevezésû RIP implementációval került forgalomba, mely segítségével a munkaállomások route-olhattak. Elôször az XNS Internet Transport Protocols nevû publikációban 1981-ben, majd 1988-ban az RFC1058-ban jelent meg formális specifikációja. 1993-ban az RFC1387-88-ban a RIP második verziója is napvilágot látott, sok ésszerû javítással, bár ekkor az OSPF már végleges formájában létezett. A RIP egyszerûsége miatt a mai napig legnépszerûbb Internetes IGP protokoll, bár idôközben több hiányosságára fény derült. Számos más routing protokollnak szolgál alapjául, például az AppleTalk RTMP-nek (Routing Table Maintenance Protocol), de a Novell, a 3Com és a Banyan is használt RIP származékokat. Mi a RIP IP verzióját tekintjük át.
A RIP alapvetôen egy lapos, egyutas, distance-vector protokoll. A RIP-et futtató router-ben konfigurálni kell az interface-eire kapcsolt hálózatok (link-ek) címeit és egy csomagnak az adott link-en való átküldésének költségeit, valamint az idôzítéshez használt idôértékeket. A célok, amikhez vezetô utakat a RIP nyilvántart, lehetnek hálózatok, subnet-ek, állomások, vagy a default router. Azt, hogy egy cím subnet vagy állomás, csak a subnet maszk segítségével lehetne eldönteni, ami viszont a RIPv1 feltételezése szerint csak az adott hálózaton belül áll rendelkezésre. Éppen ezért a hálózat határain kívülre nem szabad a hálózat belsô subnet-eit célként hirdetni, csak az egész hálózatot (subnet hiding). Hasonlóképpen egyedi állomások hirdetése sem célszerû, csak a router-ek közötti kommunikációt növeli.
A RIP egy célponthoz táblázatában a következô információkat tárolja:
A default route egy teljesen közönséges cél, amit a default router-ek hirdetnek 0 költséggel, akár többen is. Így minden router a hozzá legközelebbi default router felé irányítja az ismeretlen csomagokat.
A frissítô üzeneteket 30 másodpercenként küldik a router-ek, kis varianciával, hogy elkerüljük a szinkronizációt, azaz azt, hogy minden router egyszerre küldje frissítô üzeneteit 30 másodpercenként nagy tumultust okozva ezzel a link-en. Minden bejegyzéshez két idôzítô tartozik, az egyik a timeout, a másik a szemétgyûjtés ideje. A timeout idôzítô méri a bejegyzés utolsó frissítése óta eltelt idôt. Ha egy útvonal végtelen költségûvé válik, vagy 180 másodpercig semmiféle információ nem érkezik róla, akkor végtelenre állítjuk, azonnal szétküldünk egy üzenetet, hogy megváltozott a bejegyzés költsége és elindítjuk 120 másodpercrôl a szemétgyûjtô idôzítôt. Ha ebben az idôszakban sem változik a bejegyzés állapota, töröljük. A protokoll és split horizon, a poisoned reverse és a triggered update eszközeivel, melyeket az elôzô részben ismertettünk.
A RIP meglehetôsen robosztus és magán viseli a distance-vector protokollok két fô jellemzôjét, az egyszerûséget és a nem túl gyors konvergenciát (topológiaváltozás esetén a végtelenig számolás miatt eltelhet egy kis idô, mire stabilizálódik a router-ek állapota). A 16-os végtelen érték miatt, ha minden link költsége is csupán 1 (ami a tipikus), akkor is csak meglehetôsen kis hálózatokban használható. Ez azonban nem is baj, lévén, hogy az algoritmus nem igazán nagy hálózatokon optimális.
A RIP csomagformátumában számos tartalék mezô volt, melyek értékét kötelezôen 0-ra kell állítani. Ezeket a mezôket felhasználva az eredeti protokoll bôvítésére nyílt mód, alapvetôen két újítás került bele.
Az egyik az, hogy a célpontok címe mellett most a subnet maszkot is tartalmazza a frissítô üzenet, még a hálózat határán kívül is. Erre azért volt szükség, mert ha a hálózat belül kettészakadt úgy, hogy mindkét résznek volt kapcsolata a külvilággal, akkor bár fizikailag minden subnet elérhetô mégis elôfordulhat, hogy kívülrôl nem jut el csomag valamelyikbe. Minthogy kifelé csak a teljes hálózatot hirdetjük, csupán a véletlen mûve, hogy a 152.66.1.0 subnet-be címzett csomag a B vagy az F router-en keresztül érkezik. Ha a B-n, akkor célbatalál, ha az F-en akkor nem. Ha a subnet-ek maszkjait kívülre is terjeszthetjük, akkor az F router csak a rajta keresztül valóban elérhetô 152.66.2.0 subnet-et terjeszti kifelé és felé nem irányulnak a másik subnet-be címzett csomagok. Ezen felül lehetôvé vált változó hosszúságú subnet-ek alkalmazása is, errôl bôvebben a CIDR fejezetben olvashatunk.
A másik bôvítés a RIP csomagok hitelesítése. A RIPv1 mûködését könnyen megzavarhatja bárki, aki képes az 520-as UDP porton adni és venni, mert így magát egy RIP-et futtató router-nek álcázhatja. Példának okáért bármilyen 0 költségû utat terjeszthet, magára irányítva ezzel a forgalmat. A RIP csomagok éppen ezért hitelesítô információt hordozhatnak. Egy 16 bites mezô határozza meg a hitelesítési algoritmus típusát és 16 byte-nyi hitelesítô információ átvitelére van lehetôség minden RIP csomagban. Jelenleg csak az egyszerû jelszavas hitelesítô algoritmus definiált, amit nem túl nehéz feltörni, a jelszót kivéve a csomagból és más csomagba átmásolva máris hitelesített csomagokat küldhetünk. Olyan algoritmus, ami csak 16 byte-ot használ, idôfüggô (a csomagok letárolása és késôbbi újraküldése ellen) és biztonságos éppen kidolgozás alatt áll [2].
A RIP (és általában a distance-vector protokollok) további finomítási lehetôségekkel rendelkeznek. Ezek közül az egyik a rendszeres frissítô üzenetek között beálló szinkronizáció megtörésére vonatkozik. Bár az üzeneteket nem pontosan 30 másodpercenként küldjük, hanem ettôl egy kis, véletlen értékkel eltérô idôközönként, mégis kialakulhat a szinkronizáció, mégpedig a következôképpen. Mikor egy router-ben lejár a 30 másodperces idôzítô, nekiáll összeállítani a frissítô üzenetét. Ha eközben más router-ektôl frissítô üzenetet kap, azokat elôbb feldolgozza, majd visszatér félbehagyott munkájához. Ha elküldte üzenetét, akkor újra beállítja idôzítôjét. Így a 2 frissítô üzenet elküldése közötti idô nem 30 másodperc, hanem 30 másodperc plusz a feldolgozásra fordított idô. Ha néhány router szinkronizálódott, akkor egymás után küldik el üzeneteiket. Ha valamely másik router pont ezen elküldési idôszak alatt állítja össze üzenetét, máris szinkronizálódott. Minél több router van együtt, annál hosszabb a feldolgozási idô és annál inkább valószínû, hogy egy újabb router beleesik a már szinkronizálódott csoportba, azon router-ek közé, akik szinte egyidôben adják és veszik frissítô üzeneteiket. Erre megoldás, ha a frissítési idô szélesebb skálán 15 és 45 másodperc között változik véletlenszerûen. Ez elég nagy variancia a már kialakult szinkron csoportok megtöréséhez is.
Másik javítási lehetôség adódik a 30 másodpercenkénti frissítô üzenetek elhagyásával. Így különösen stabil hálózatok esetén jelentôsen csökkenthetô a routing protokoll által generált forgalom. Különösen ott elônyös ez, ahol „hallgatni arany", a kapcsolatorientált hálózatok felett, ahol a (különösen a ritkán elküldött) csomag postázása elôtt kapcsolatfelépítés szükséges. Ha nem küldünk periodikus frissítést, akkor viszont nyugtázni kell a topológiaváltozás hatására elküldött frissítô üzeneteket. Akkor azonban, ha azt halljuk, hogy egy hálózat az eddigi irányban elérhetetlen, semmiféle lehetôségünk nincs arra, hogy kitaláljuk, vajon más irányba elérhetô-e. Eddig ilyenkor vártunk a periodikus frissítô üzenetekre és azokban kerestünk a végtelennél olcsóbb utat. Most viszont vagy minden szomszédunk teljes „útajlánlatát" le kell tárolni, vagy magunknak kell lekérdezni azt a célpontot, amire szükségünk van. Az egyik sok memóriát igényel, a másik pedig minden szomszéd megszólítását, ami a hallgatni arany, beszélni egy egység a telefonkártyáról elv alapján elég drága lehet.
A RIP által használt primitív költség-rendszert is javíthatjuk összetett költségek bevezetésével. Az IETF SIP munkacsoportja kidolgozott egy ilyen összetett költséget. A költség egyik eleme lehetne a hop-számláló, ami jelezheti a végtelen értéket, a másik pedig az adott link sávszélessége. Mikor egy újabb szegmenst adunk az útvonalhoz, a hop-számlálót egyel növeljük (csakúgy mint a RIP-ben, ha 1 a link költsége), a sávszélességek közül pedig a kisebbet vesszük. A hosszú útvonalak kiküszöbölése érdekében a kapott sávszélességet még mintegy 20%-kal csökkentjük. A választás kritériuma a sávszélesség, azonos sávszélességek esetén pedig a hop-számláló.
Mindezen csiszolások azonban nem érintik a distance-vetcor protokollok fô problémáját, a hurkok kialakulását. Erre a source-tracking (forrás-nyomonkövetés) módszere jelenthet megoldást. Lényege, hogy a routing táblázatokban nemcsak a célpont címét és a költséget tüntetjük fel, hanem az odavezetô úton a célponthoz legközelebb esô router címét is. Ha bejegyzésünket terjesztjük, akkor a legközelebbi router címét változtatás nélkül továbbadjuk. Ilyen módon minden célponthoz képesek vagyunk rekonstruálni az útvonalat, ha minden router célként szerepel táblázatunkban. B szemszögébôl például az X célponthoz E a legközelebbi router, ahhoz A, A-hoz pedig B maga. Ha kialakulna az A, B, C hurok, akkor ez is hamar kiderülne.
A vázolt algortimus igen elegáns, bár nem könnyû a RIP-be integrálni. Elôször is új mezôket kellene bevezetni a frissítô üzenetekbe a legközelebbi router címének továbbadására. Másodszor egy router-nek több címe van, minden interface-hez egy-egy. Vajon melyiket használjuk? Másfelôl viszont feltételezzük, hogy a fenti példát alapul véve B-ben minden router-hez van bejegyzésünk (nevezetesen E-hez és A-hoz), ami alapján összeállíthatjuk az útvonalat. Ez nem igaz a RIP-ben, ahol legjobb esetben is minden link-hez (subnet) van bejegyzésünk. A router-ek címét tehát párosítani kellene a link-ek címeivel.
Az említett nehézségek mind leküzdhetôek lennének, az érzékelt hurkokat a költség végtelenre állításával azonnal feloldhatnánk, mégis általános a vélemény, hogy a megoldás ellentétben van a RIP egyszerû implementálhatóságával és jelentôsen megnövelné a szükséges számítási teljesítményt.