Demone NTKD - Analisi Funzionale

Il demone ntkd deve essere sempre in esecuzione su ogni singolo nodo che compone una rete Netsukuku. Gli obiettivi che si prefigge sono:

Funzionamento di una rete Netsukuku

Una rete Netsukuku è costituita da un gruppo di nodi fra loro collegati attraverso un qualsiasi mezzo, come dei cavi collegati ad uno switch, o delle radio Wi-Fi a distanza di rilevamento. Una singola rete deve essere completamente connessa, cioè dati due nodi qualsiasi deve esistere un percorso che li unisce costituito da nodi tra loro collegati. Questi nodi possono essere dei computer, o degli access point, o altri dispositivi sui quali, come già detto, deve essere in esecuzione il demone ntkd .

Se si formano due gruppi di nodi fra loro collegati, ma non esiste alcun collegamento fra singoli nodi del gruppo A e del gruppo B, tali gruppi sono "isole" Netsukuku. Fin quando non si incontrano, essi costiuiscono due reti Netsukuku distinte e separate.

Nel resto del documento ci riferiamo a "la rete Netsukuku" volendo con questo termine indicare una qualunque di queste isole.

Un nodo della rete Netsukuku deve essere configurato inizialmente con queste informazioni:

Inoltre il nodo deve avere configurato come servizio sempre in esecuzione il demone ntkd .

Una volta soddisfatti questi requisiti il nodo è parte della rete Netsukuku. Ciò significa che è in grado di contattare o di essere contattato da qualsiasi altro nodo nella rete Netsukuku. Il demone ntkd esplora la rete Netsukuku, fornisce le informazioni rilevanti allo stack TCP/IP del S.O. e usa il sistema di nomi ANDNA per registrare i suoi nomi e risolvere i nomi degli altri nodi.

Attenzione: Un nodo che è parte di una rete Netsukuku può fare allo stesso tempo parte anche di un'altra rete TCP/IP privata o di Internet. Le due cose non sono tra loro incompatibili. Allo stesso modo, oltre a usare il sistema ANDNA può continuare ad usare sull'altra rete il sistema DNS.

Esplorazione della rete

L'algoritmo distribuito di esplorazione della rete ha obiettivi che vanno oltre le finalità di un classico sistema di routing nelle reti TCP/IP. Per capirlo meglio, analiziamo dapprima quali informazioni siano necessarie ad un nodo di una classica rete TCP/IP. Vediamo poi quali differenze si presentano in una rete di tipo mesh. Infine descriveremo quali informazioni ottiene ogni singolo nodo di una rete Netsukuku dall'esecuzione dell'algoritmo distribuito di esplorazione.

Tabelle di routing di una classica rete TCP/IP

Molto spesso, in un nodo terminale di una classica rete TCP/IP abbiamo una sola interfaccia di rete attiva, che può essere la scheda ethernet attraverso la quale siamo collegati con un cavo, oppure la scheda radio attraverso la quale siamo connessi ad un access point. In entrambi i casi, attraverso questa interfaccia abbiamo un nostro indirizzo IP e nelle tabelle di routing una rotta diretta verso un numero di indirizzi che possono essere assegnati a nodi che sono connessi allo stesso modo alla nostra cosidetta LAN. Tra questi nodi, uno in particolare viene definito default gateway , perché è attraverso di lui che possiamo raggiungere il resto della rete, ad esempio Internet o la rete aziendale. Abbiamo, cioè, nelle tabelle di routing una rotta che dice di passare per l'indirizzo assegnato a quel gateway per raggiungere la classe di indirizzi che rappresenta l'intera rete.

Molto più raramente, un nodo terminale di una rete TCP/IP potrebbe avere due interfacce di rete entrambe attive, di solito una ethernet e una radio. Per ognuna di esse abbiamo un indirizzo IP (usato di preferenza come indirizzo sorgente per i messaggi che partono da questo nodo e escono da questa interfaccia) e nelle tabelle una rotta diretta per una classe di indirizzi. Siamo cioè collegati a due LAN. Potremmo avere su ogni LAN un gateway (raramente più di uno). Ad esempio, siamo collegati alla rete aziendale attraverso un cavo di rete, e anche ad un access point tramite la scheda radio. Attraverso l'interfaccia cablata vediamo la LAN del nostro ufficio; in particolare un nodo di questa LAN ci serve come gateway per raggiungere dei server che sono in altri uffici della stessa azienda. Però siccome non possiamo accedere a Internet attraverso questa rete aziendale, abbiamo un access point che ci collega ad un Internet Provider. In questo caso abbiamo 2 indirizzi propri e 4 rotte nelle tabelle. Per esempio, 192.168.100.14 come indirizzo preferito per la scheda ethernet, una rotta diretta attraverso la scheda ethernet per la classe 192.168.100.0/24 e una rotta per la classe 192.168.0.0/16 che passa per il gateway 192.168.100.1 nell'interfaccia ethernet. Poi abbiamo 192.168.2.101 come indirizzo preferito per la scheda radio, una rotta diretta attraverso la scheda radio per la classe 192.168.2.0/24 e una rotta per la classe di indirizzi dell'intera rete, la 0.0.0.0/0, che passa per il gateway 192.168.2.1 nell'interfaccia radio.

In questo caso il nostro nodo è collegato a due LAN. Ma gli altri nodi delle due LAN non sanno dell'esistenza della LAN in cui non si trovano. Il nostro nodo non viene usato come gateway da una LAN verso l'altra.

Questo scenario è un po' più complesso del solito. Affrontare con il solito approccio questa maggiore complessità pone alcune limitazioni. Nel caso descritto sopra, la rete aziendale vuole pieno controllo degli indirizzi nella classe 192.168.0.0/16. Probabilmente sono troppi, ma per facilità attua questa politica. L'access point del provider di Internet vuole il controllo della classe 192.168.2.0/24. Questo comporta che eventuali nodi della rete aziendale con indirizzi in quest'ultima classe non saranno raggiungibili dal mio nodo terminale collegato alle due LAN.

Iniziamo ora ad esaminare i nodi router di una classica rete TCP/IP. Cioè quei nodi che hanno almeno due interfacce di rete collegate a due LAN distinte e che sono in grado di smistare i messaggi che devono passare dall'una all'altra.

Un router con n interfacce di rete connesse ad altrettante LAN, ha di norma n indirizzi propri, ognuno nello spazio di indirizzi assegnato ad una LAN a cui è connesso. Ha inoltre n rotte dirette nel kernel, ognuna delle quali dice di poter raggiungere direttamente attraverso una certa interfaccia tutti gli indirizzi della classe assegnata alla LAN a cui l'interfaccia è connessa. Poi ha un insieme R di altre rotte. Questo insieme può essere piccolo o anche molto grande. Ogni rotta r ∈ R dice che un messaggio destinato ad un indirizzo appartenente alla classe d può essere consegnato ad un certo gateway gw attraverso l'interfaccia nic .

Le conoscenze di un router di una classica rete TCP/IP gli permettono, date le informazioni contenute in un pacchetto p, di individuare la regola r che meglio lo inquadra e così di inoltrarlo attraverso uno dei suoi gateway.

Queste informazioni sono carenti in quanto di norma non consentono di scegliere fra più possibili alternative. Dato un indirizzo di destinazione è sempre una sola la rotta che il pacchetto dovrà prendere. Se la destinazione potesse essere effettivamente raggiunta attraverso diversi percorsi dingiunti, questa carenza porta ad uno sfruttamento non ottimale delle risorse.

Queste informazioni sono anche carenti nella conoscenza del percorso oltre al primo hop, cioè oltre il proprio gateway. Le informazioni nella tabella di routing, cioè, non dicono quanti e quali altri router andranno percorsi per raggiungere la destinazione.

Nonostante la scarsità di informazioni mantenute, le dimensioni della tabella di routing di un router del core di Internet sono ad oggi un problema. Il protocollo di routing standard usato da questi router per gestire le interconnessioni tra i vari Autonomous Systems che costituiscono l'intera Internet è il BGP. Nell'ultimo anno (agosto 2014) il numero di rotte presenti in alcuni router ha superato le 500000.

I protocolli di routing, come il BGP appena citato, cercano di esplorare in modo dinamico la rete, al fine di rendere possibile lo sfruttamento dei migliori percorsi. Questi protocolli però sono usati solo ai livelli "alti" della rete Internet, nella sua dorsale. Nelle parti più periferiche, quelle che sono più direttamente percepite dall'utenza finale, come anche nelle reti TCP/IP di piccole dimensioni come le intranet aziendali, si usa di norma un approccio statico e centralizzato. Gli indirizzi sono assegnati in modo statico da un ente di controllo centrale e anche le rotte sono fisse. Per rendere queste ultime facilmente mantenibili si adotta una topologia di rete cosidetta a stella.

Si tratta di una topologia fortemente gerarchica. Quando un nodo vuole comunicare con un altro, fosse anche molto vicino a lui, è costretto a seguire un percorso verso il nodo centrale della stella, per poi allontanarsene verso il vertice destinazione.

Tabelle di routing di una rete mesh

L'obiettivo che si propone una rete mesh è che ogni nodo che vuole raggiungere una destinazione sia in grado di sfruttare il miglior percorso fisicamente fruibile nella rete, senza essere costretto a seguire un percorso altamente gerarchico.

Un altro obiettivo desiderabile è che ogni nodo sia in grado di raggiungere qualsiasi altro indirizzo appartenente alla rete; cioè non ci devono essere porzioni di rete che vengono nascoste (NATtate) dietro un unico indirizzo pubblico e che quindi sarebbero in grado di operare solo come iniziatori di connessione (client) verso altri nodi con un indirizzo pubblico.

Spesso, gli indirizzi dei singoli nodi di una rete mesh vengono assegnati in modo statico. Anche le varie tabelle di routing potrebbero in teoria venire popolate manualmente una volta per tutte, ma questo raramente accade e si presta solo a reti molto piccole. Di norma il popolamento delle tabelle di routing è l'obiettivo di un software che implementa un routing protocol.

In una rete mesh non esiste il concetto di nodo terminale. Ogni singolo nodo può operare da gateway per un suo vicino che gli trasmette un pacchetto per una qualsiasi destinazione.

Consideriamo un nodo che ha più interfacce di rete tramite le quali è connesso ad altri nodi. Di norma in una rete mesh questo nodo non associa a una interfaccia un'intera classe di indirizzi. Invece memorizza nelle tabelle di routing una singola rotta diretta per l'indirizzo di ogni vicino di cui viene a conoscenza attraverso il protocollo di routing.

Sempre attraverso il protocollo di routing, il nodo viene a conoscenza di altre informazioni sulla rete e questo gli permette di popolare le tabelle di routing con altre rotte.

Anche in questo caso le rotte sono costituite da poche informazioni: dato un messaggio per una destinazione d esso va consegnato al gateway gw attraverso l'interfaccia nic . Questo anche se le informazioni raccolte attraverso il protocollo di routing potrebbero essere più dettagliate.

Informazioni raccolte da un nodo Netsukuku

A

Stack TCP/IP

Il software nella suite Netsukuku non intende sostituire lo stack TCP/IP implementato nel S.O. del nodo. Nemmeno intende interagire con le librerie TCP/IP del S.O. attraverso sistemi di hook.

Quando un'applicazione vuole avviare una connessione TCP con un indirizzo, o inviare un pacchetto di dati UDP ad un nodo, o mettersi in ascolto, o qualsiasi altra operazione che coinvolge la rete TCP/IP, questi eventi non sono in alcun modo notificati al software Netsukuku. Sono invece completamente gestiti alla vecchia maniera dalle librerie del S.O. del nodo.

Infatti non è in questo momento che il software Netsukuku intende operare, ma preventivamente. Le sue operazioni mirano a popolare in anticipo le tabelle di routing del nodo con le rotte di sua pertinenza e mantenerle aggiornate. Si definiscono rotte di pertinenza di Netsukuku tutte le rotte necessarie a che ogni singolo nodo esistente nella rete Netsukuku possa essere raggiunto e che ogni indirizzo nello spazio di Netsukuku che non è stato assegnato ad alcun nodo sia riportato come "irraggiungibile".

Il demone ntkd mantiene le rotte di pertinenza di Netsukuku nelle tabelle di routing. Decide quali rotte impostare sulla base delle informazioni che ha raccolto tramite l'esplorazione della rete.

Specificare. TODO

Associazione nomi - indirizzi

La suite di software Netsukuku offre un meccanismo di risoluzione dei nomi degli host chiamato ANDNA (A Netsukuku Domain Name Architecture).

ANDNA si propone come meccanismo alternativo o in aggiunta al classico DNS. Tra i due sistemi si evidenziano queste differenze:

Ogni singolo nodo della rete Netsukuku può cercare di registrare per se stesso un numero illimitato di nomi. L'algoritmo distribuito consente ad ogni singolo nodo di vedere accettata la registrazione di un totale di 256 nomi che non siano già stati assegnati ad altri nodi.

Quando un nodo ottiene la registrazione di un nome, questa rimane attiva per 30 giorni. Fino a quando la registrazione è attiva nessun altro nodo potrà registrare per se lo stesso nome. La registrazione può essere aggiornata dal nodo che la detiene, il quale si autentica al sistema distribuito ANDNA attraverso un meccanismo di cifratura asimmetrica (chiave pubblica / chiave privata). Quindi il conteggio dei 30 giorni riparte da capo.

Tutto il back-end di ANDNA (la registrazione dei nomi, l'applicazione delle politiche delineate sopra, la ricerca dei nomi) è realizzato attraverso due servizi peer-to-peer chiamati Andna e Counter. La spiegazione del loro funzionamento non rientra nell'ambito di questo documento.

Il front-end di ANDNA, cioè quello che succede quando una applicazione chiede una informazione al cosidetto resolver dei nomi del S.O. del nodo su cui è in esecuzione, si compone di due parti: una client e una server.

La parte server è realizzata dallo stesso demone ntkd. Esso riceve le richieste dalla parte client e risponde dopo aver interrogato il back-end.

La parte client può essere interpretata da diversi moduli software, i quali si interfacciano con le applicazioni in diversi modi a seconda dei meccanismi messi a disposizione del S.O. . I moduli client forniti dalla suite Netsukuku (lilbnss_andna , dns-to-andna , ntk-resolv ) sono descritti in dettaglio in un altro documento.