Bonjour: cosa si nasconde dietro l’im­ple­men­ta­zio­ne Zeroconf

I di­spo­si­ti­vi nelle reti per poter co­mu­ni­ca­re tra di loro devono prima di tutto in­stau­ra­re una con­nes­sio­ne. Per prendere contatto non hanno bisogno del nome del di­spo­si­ti­vo ma dell’indirizzo IP o MAC che viene so­li­ta­men­te assegnato in au­to­ma­ti­co ai membri delle reti più grandi tramite un server DHCP prin­ci­pa­le (Dynamic Host Con­fi­gu­ra­tion Protocol). Così assiste il server DNS che è re­spon­sa­bi­le per la tra­sfor­ma­zio­ne del nome di dominio in un indirizzo IP e viceversa. L’al­ter­na­ti­va a questa as­se­gna­zio­ne au­to­ma­ti­ca di indirizzo consiste nel mo­di­fi­ca­re i file host di tutti i membri della rete e di inserire ma­nual­men­te i nomi e gli indirizzi IP, un’impresa che in una rete più grande, è sem­pli­ce­men­te im­pos­si­bi­le da mettere in atto. Entrambi i metodi uti­liz­za­ti per la con­fi­gu­ra­zio­ne di una rete locale sono perciò tutt’altro che ideali: da un lato anche la con­fi­gu­ra­zio­ne di server DHCP e DNS è su­bor­di­na­ta a de­ter­mi­na­te co­no­scen­ze e a un certo impegno, dall’altro la variante manuale richiede sempre la modifica di tutti i file host, se ad esempio si aggiunge un nuovo di­spo­si­ti­vo alla rete o se sono ne­ces­sa­rie delle modifiche ai sistemi già integrati. La soluzione al problema prende il nome di Zero Con­fi­gu­ra­tion Net­wor­king, ab­bre­via­to in Zeroconf, e indica l’idea di una rete IP che collega i di­spo­si­ti­vi senza con­fi­gu­ra­zio­ne manuale. Il concetto di rete, elaborato da un gruppo di lavoro della IETF (Internet En­gi­nee­ring Task Force) tra il 1999 e il 2003, è stato rea­liz­za­to nelle im­ple­men­ta­zio­ni Bonjour e Avahi.

Quando la Internet En­gi­nee­ring Task Force ha iniziato nel 1999 il progetto Zero Con­fi­gu­ra­tion Net­wor­king, si è pre­fis­sa­ta come obiettivo le seguenti ca­rat­te­ri­sti­che per la rea­liz­za­zio­ne di una “con­nes­sio­ne di rete senza con­fi­gu­ra­zio­ne”:

• ri­so­lu­zio­ne del nome di dominio integrata;
• as­se­gna­zio­ne au­to­ma­ti­ca della maschera di sottorete, dell’indirizzo IP e del router;
• funzione di ricerca per trovare dei servizi di rete di­spo­ni­bi­li;
• as­se­gna­zio­ne au­to­ma­ti­ca di indirizzi multicast per con­nes­sio­ni con più di­spo­si­ti­vi;
• stesso livello di sicurezza presente anche sulle reti senza Zeroconf.

Il gruppo di lavoro della IETF non è riuscita a trovare un accordo e perciò alla fine del progetto non ha pub­bli­ca­to neanche un documento con i requisiti del Zero Con­fi­gu­ra­tion Net­wor­king. Si è scelto, invece, insieme ad Apple, Microsoft e Sun Mi­cro­sy­stems, di elaborare una spe­ci­fi­ca­zio­ne per il pro­to­col­lo Internet, ri­la­scia­ta nel 2005 con il nome di “Dynamic Con­fi­gu­ra­tion of IPv4 Link-Local Adresses“ (RFC 3927).

IPv4LL assegna au­to­ma­ti­ca­men­te indirizzi IP casuali con il prefisso 169.254/16, quindi compresi tra gli indirizzi 169.254.0.x e 169.254.255.x, anche se i primi e gli ultimi 256 indirizzi sono destinati a essere occupati da future ap­pli­ca­zio­ni. Inoltre lo standard RFC prevede che il ge­ne­ra­to­re casuale al momento della ge­ne­ra­zio­ne degli indirizzi Internet tenga in con­si­de­ra­zio­ne in­for­ma­zio­ni spe­ci­fi­che del computer, come ad esempio gli indirizzi MAC dell’in­ter­fac­cia di rete, cosa che riduce la pos­si­bi­li­tà che due di­spo­si­ti­vi ricevano lo stesso IP.

Come funziona l’as­se­gna­zio­ne au­to­ma­ti­ca degli indirizzi nel pro­to­col­lo IPv4

Per l’as­se­gna­zio­ne au­to­ma­ti­ca degli indirizzi senza il pro­to­col­lo DHCP, l’IPv4 si serve dell’Address Re­so­lu­tion Protocol (ARP) che nell’IPv6 è stato so­sti­tui­to dal Neighbor Discovery Protocol (NDP). Così il processo di as­se­gna­zio­ne at­tra­ver­sa diversi passaggi per evitare conflitti tra gli indirizzi IP dei di­spo­si­ti­vi di rete presenti.

1. Prima di tutto viene generato l’indirizzo IP.
2. Dopo l’IPv4LL prevede i così chiamati ARP Probe dove viene ve­ri­fi­ca­to se l’indirizzo IP generato venga già uti­liz­za­to nella rete. Per questo i tre pacchetti ARP con l’indirizzo del mittente 0.0.0.0 e l’indirizzo da ve­ri­fi­ca­re vengono inviati come de­sti­na­ta­ri.
3. Se in questo periodo di tempo viene ricevuto un pacchetto ARP in cui l’indirizzo del mittente cor­ri­spon­de all’indirizzo IP generato, ciò significa che è già stato dato nella rete e la ge­ne­ra­zio­ne IP ri­co­min­cia daccapo.
4. Se viene ricevuto un ARP Probe estraneo che è con­tras­se­gna­to con l’indirizzo da testare significa che almeno un altro di­spo­si­ti­vo tenta di entrare nella rete con questo IP e perciò la procedura viene ripetuta di nuovo ri­co­min­cian­do dal primo passaggio.
5. Se il conflitto permane, il di­spo­si­ti­vo che prova a con­net­ter­si ha richiesto l’indirizzo uscendone vincitore e invia due ARP An­noun­ce­men­ts (“co­mu­ni­ca­zio­ni”), dove l’indirizzo del mittente e del de­sti­na­ta­rio cor­ri­spon­do­no all’IP generato.

Dato che l’indirizzo IP assegnato è dinamico, questo viene di nuovo ve­ri­fi­ca­to ad ogni riavvio, ad ogni so­spen­sio­ne dalla modalità stand-by, ad ogni in­se­ri­men­to del cavo ethernet o ad ogni login nella rete Wi-Fi. Per evitare che un elevato numero di conflitti porti a un so­vrac­ca­ri­co della rete, ad esempio nel caso in cui molti di­spo­si­ti­vi si vogliano con­net­te­re si­mul­ta­nea­men­te alla rete, il numero di nuovi tentativi per di­spo­si­ti­vo viene au­to­ma­ti­ca­men­te ridotto dopo dieci conflitti a una verifica al minuto.

Zeroconf: ri­so­lu­zio­ne del nome di dominio e ri­co­no­sci­men­to au­to­ma­ti­co dei di­spo­si­ti­vi

Insieme al gruppo di lavoro DNS Ex­ten­sions il team di Zeroconf ha svi­lup­pa­to anche delle soluzioni per la tra­du­zio­ne au­to­ma­ti­ca degli indirizzi e la gestione dei di­spo­si­ti­vi nelle reti IPv4 senza con­fi­gu­ra­zio­ne. Al posto di ideare un pro­to­col­lo com­ple­ta­men­te nuovo, si è deciso di offrire queste funzioni tramite delle semplici modifiche del pro­to­col­lo DNS standard. Così i gruppi del progetto hanno lavorato a stretto contatto con Apple, perché l’azienda di elet­tro­ni­ca aveva già trovato con la propria raccolta di pro­to­col­li AppleTalk delle soluzioni adeguate per i propri di­spo­si­ti­vi, che dovevano solo essere impiegate nella famiglia di pro­to­col­li Internet. Sono risultate così le spe­ci­fi­ca­zio­ni Multicast DNS (RFC 6762) e DNS-Based Service Discovery (RFC 6763).

Multicast DNS (mDNS) descrive come i di­spo­si­ti­vi possono inviare richieste DNS agli indirizzi IP multicast. Per questo motivo il Top-Level-Domain .local è definito nel pro­to­col­lo mDNS come link local. Inoltre tutte le richieste che terminano per .local devono essere inviate all’indirizzo IPv4LL multicast 224.0.0.251 (nell’IPv6 l’indirizzo è FF02::FB). Nel caso in cui la rete non disponga di un server DNS, tutte le richieste DNS che non terminano per .local giungono ugual­men­te all’indirizzo multicast.

In generale i messaggi mDNS possono sia essere trasmessi tramite UDP sia tramite TCP. Così, al posto della solita porta 53, viene uti­liz­za­ta la porta multicast 5353. Se ora un di­spo­si­ti­vo di rete volesse risolvere il nome host di un altro membro della rete, gli invia una richiesta mDNS chie­den­do­gli di iden­ti­fi­car­si. Il di­spo­si­ti­vo di de­sti­na­zio­ne risponde con un pacchetto multicast che rivela il suo indirizzo IP. Tutti i di­spo­si­ti­vi di rete ricevono questa in­for­ma­zio­ne e la me­mo­riz­za­no au­to­ma­ti­ca­men­te nella loro cache DNS.

DNS-Based Service Discovery (DNS-SD) definisce come i servizi in una rete Zeroconf possano essere visibili e resi di­spo­ni­bi­li per tutti i membri. Per evitare conflitti è prima di tutto ne­ces­sa­rio re­gi­stra­re questi servizi presso la IANA (Internet Assigned Numbers Authority) per ricevere un nome del servizio as­se­gna­bi­le uni­vo­ca­men­te. Poi le ap­pli­ca­zio­ni co­mu­ni­ca­no il relativo nome ai membri della rete tramite una notifica multicast, dove non si presenta alcun problema quando più di­spo­si­ti­vi offrono lo stesso servizio: il client di rete che richiede l’accesso ha in questo caso la pos­si­bi­li­tà di scegliere uno degli host.

La IETF ha pub­bli­ca­to uf­fi­cial­men­te entrambe le spe­ci­fi­ca­zio­ni RFC solo a febbraio 2013, ma Apple aveva già iniziato come promotore nel 2012 a integrare gli standard nei suoi di­spo­si­ti­vi. Il software open source svi­lup­pa­to in questa occasione, co­no­sciu­to oggi con il nome di Bonjour (prima Ren­dez­vous), rientra senza ombra di dubbio tra le soluzioni Zeroconf più diffuse og­gi­gior­no. Così l’ar­chi­tet­tu­ra di rete senza con­fi­gu­ra­zio­ne non solo è di­spo­ni­bi­le per macOS e iOS ma anche per i sistemi Windows.

Quando Apple nel 2001 è passato con il Mac OS X 10.0 al kernel ibrido XNU, si è deciso di non uti­liz­za­re sul nuovo sistema operativo il gruppo di pro­to­col­li di rete di AppleTalk, fino ad allora tipici. Ma a Stuart Cheshire, utente Mac, non era neanche passato per la mente che il gigante dell’elet­tro­ni­ca non avesse più in­ten­zio­ne di svi­lup­pa­re un suc­ces­so­re adeguato e perciò animò con un’e-mail una di­scus­sio­ne in cui af­fron­ta­va con altri utenti le vul­ne­ra­bi­li­tà della con­fi­gu­ra­zio­ne di rete manuale, diventata ormai ne­ces­sa­ria.

Ciò ha dato da pensare ad Apple: seduta stante Stuart Cheshire è stato assunto e gli è stato assegnato l’incarico di svi­lup­pa­re una variante di pro­to­col­lo per il nuovo sistema operativo, risultato dalla già citata col­la­bo­ra­zio­ne con la Internet En­gi­nee­ring Task Force.

Con il Mac OS X 10.2 Apple ha ri­la­scia­to nell’agosto 2002 la prima versione della nuova spe­ci­fi­ca­zio­ne di pro­to­col­lo con il nome Ren­dez­vous. Per via di com­pli­ca­zio­ni legali si è dovuto trovare un nuovo nome al progetto, motivo per cui il software di rete porta a partire dalla versione 10.4 il nome valido ancora oggi di Bonjour. Il com­po­nen­te prin­ci­pa­le del pacchetto è mDN­SRe­spon­der, un programma che si avvia durante il boot e funziona in back­ground, im­ple­men­tan­do multicast DNS e DNS-Based Service Discovery. Inoltre ad oggi tra i com­po­nen­ti prin­ci­pa­li rientra anche la spe­ci­fi­ca­zio­ne del pro­to­col­lo Internet IPv4LL e IPv6LL. Così la soluzione di Apple comprende le tre sezioni ele­men­ta­ri della rete senza con­fi­gu­ra­zio­ne:

• In­di­riz­za­men­to
• Ri­so­lu­zio­ne del nome di dominio
• Ri­co­no­sci­men­to del servizio di rete

Grazie a questa ar­chi­tet­tu­ra in­stau­ra­te fa­cil­men­te una con­nes­sio­ne con il vostro di­spo­si­ti­vo agli altri com­po­nen­ti nelle reti locali che ricorrono a loro volta a Bonjour, in­di­pen­den­te­men­te che si tratti di un PC, una stampante o di un’ap­pli­ca­zio­ne. Così, tra gli altri, anche il servizio di musica di Apple, iTunes, utilizza questa tec­no­lo­gia di modo che vengano trovati au­to­ma­ti­ca­men­te altri utenti che mettono a di­spo­si­zio­ne la loro musica in rete.

Bonjour è in­stal­la­to au­to­ma­ti­ca­men­te sui sistemi attuali di macOS e iOS. Gli utenti Windows possono scaricare una versione specifica per i servizi di stampa o in al­ter­na­ti­va in­stal­la­re un’ap­pli­ca­zio­ne in cui è contenuto il software. Tra questi rientrano anche il già citato iTunes, Skype e Adobe Photoshop (a partire dalla versione CS3).

Un’al­ter­na­ti­va alla soluzione Zeroconf di Apple che funziona anche sui sistemi Linux, in­stal­la­ta di norma su Debian e Ubuntu e di­spo­ni­bi­le con licenza libera LGPL, è Avahi. L’im­ple­men­ta­zio­ne è stata ini­zial­men­te sup­por­ta­ta grazie all’ini­zia­ti­va a scopi sociali free­de­sk­top.org, ma si è tra­sfor­ma­ta ora in un progetto in­di­pen­den­te.