|
|
Lo sviluppo della seconda versione di RIP ha sostanzialmente diviso l'opinione degli esperti: alcuni hanno condiviso la scelta, altri invece sostenevano che i protocolli basati sull'algoritmo distance vector fossero in generale obsoleti e dovessero essere quindi abbandonati e rimpiazzati da piu' moderni protocolli quali OSPF e IS-IS. RIP-2 e' specificato da Gary Malkin nella RFC-1388 che, tra l'altro, riassume le "giustificazioni" che hanno portato allo sviluppo della revisione: in pratica, seppur riconoscendo la superiorita' dei nuovi protocolli IGP, si sostiene che RIP presenta comunque sempre alcuni vantaggi, come il piccolo overhead in termini di occupazione di banda su piccole reti o la semplicita' di implementazione, configurazione e gestione del protocollo e i bassi tempi richiesti a questo scopo.
Al di fuori della sottorete, RIP vers.1 non e' in grado di interpretare la subnet mask e, quindi, di distinguere tra una sottorete e un host. RIP-2 permette invece l'instradamento anche al di fuori della sottorete, trasmettendo l'informazione della netmask in parallelo all'indirizzo. La maschera viene passata in uno dei campi "must be zero" di RIP-1 che, di conseguenza, e' in grado di ignorare le entries RIP-2.
RIP-1 non e' un protocollo sicuro. Qualsiasi host che invia pacchetti dalla porta UDP 520 verrebbe considerato un router dai propri vicini, mentre invece solo un utente privilegiato dovrebbe avere il diritto di utilizzare questa porta. A questo scopo, RIP-2 prevede una procedura di autenticazione che specifica che la prima entry in un pacchetto puo' essere rimpiazzata da un "authentication segment". Il pacchetto conterra' quindi l'header iniziale a 32 bit, seguito da un segmento di autenticazione composto da :
ed infine da 24 coppie di campi destinazione-metrica. I routers RIP-1 semplicemente rilevano che il campo AFI non risulta pari a 2 e quindi non considerano l'authentication segment, procedendo con le 24 rimanenti entries. Alla ricezione del pacchetto, il router RIP-2 verifica la presenza dei campi di autenticazione e, in caso affermativo, ne rivela l'origine. Esistono svariati algoritmi di autenticazione, definiti attraverso il campo Authentication Type; in comune vi e' la protezione dei messaggi di aggiornamento attraverso una password criptata.
Vi sono numerosi casi dove 2 autonomous system condividono lo stesso cavo di rete (es. FDDI, Ethernet), specialmente quando questo cavo e' utilizzato come backbone per connettere reti diverse. Questo puo' generare dei problemi. Vediamo l'esempio della rete in figura:
Per inviare un pacchetto alla destinazione F del dominio Y, il router A del dominio X invia il pacchetto a D, che e' la nominale interfaccia della rete Y verso la rete X. Il nodo D conoscera', attraverso le tabelle di routing del dominio Y che la strada migliore per F passa attraverso il router E e quindi ritrasmettera' il pacchetto. In pratica il pacchetto viaggia 2 volte sulla stessa rete : da A a D e poi da D ad E: questo non e' chiaramente ottimale. RIP-2 risolve questo problema introducendo il concetto di "next-hop": il router D sa che i pacchetti verso F passano attraverso il router E e quindi, quando invia un aggiornamento ad F non invia solamente la coppia indirizzo-metrica ma anche l'indicazione "next hop", dicendo ai routers come A che " la distanza verso F e' f, ma la strada migliore non e' tramite me (D) ma attraverso E". In questo modo, i routers come A saranno in grado di indirizzare direttamente i pacchetti verso E, evitando l'extra hop attraverso D.
RIP-1 utilizza un indirizzo broadcast per inviare avvisi di routing a "tutti i pacchetti su un cavo". Come risultato, questi pacchetti saranno ricevuti non solo dai routers ma da tutti gli host su quel cavo. Non esiste un modo pratico di programmare un'interfaccia di rete Ethernet o Token Ring per filtrare tutti i pacchetti broadcast; un simile filtraggio si puo' ottenere attraverso un indirizzo MAC multicast, che verra' rilevato solo dai routers. RIP-2 non definisce esattamente un indirizzo MAC ma raggiunge lo stesso scopo definendo l'indirizzo IP di classe D 224.0.0.9 al fine di essere utilizzato per multicast periodici. Le operazioni in modalita' multicast tuttavia compromettono la compatibilita' con RIP-1 per cui sono state definite 3 modalita' operative :
La prima modalita' garantisce piena compatibilita' ma non porta vantaggi; la seconda modalita' corrisponde alla transizione ed e' utilizzata finche' alcuni routers nell' autonomous system rimangono "solo RIP-1". Questi routers vedranno i pacchetti RIP-2 ed occasionalmente ne scarteranno alcune parti, ad esempio le informazioni sull'autenticazione o sul subnet. Infine, la terza modalita' corrisponde alla fase finale, quando tutti i routers sono stati aggiornati a RIP-2.
|
Il campo AFI settato a oxFFFF