Approfondimento tecnico
    Networking Plug & Play
Telecom Italia logo
     English | ngnet.it home >> Cos´è IPv6 >> Il protocollo IPv6 >> Networking Plug & Play  
previous next
Networking Plug & Play

IPv6 mira a diventare un protocollo plug & play, il che significa che sarà sufficiente collegare fisicamente una macchina alla rete affinché questa proceda automaticamente alla propria configurazione e sia così in grado di comunicare con le altre macchine. Per ottenere questo, sono necessari quattro tipi di autoconfigurazione: degli host, dei router, del DNS e dei servizi.

Autoconfigurazione degli host

Per autoconfigurazione degli host si intende un meccanismo che consente di assegnare degli indirizzi e altri parametri alle interfacce di rete. Si hanno due possibilità: usare quella che viene detta autoconfigurazione stateful o quella stateless.

Nel modello stateful, un host ottiene l'indirizzo (e altri parametri) per un'interfaccia in seguito all'interrogazione di un server, fatta usando DHCPv6, estensione per IPv6 del protocollo DHCP (Dynamic Host Configuration Protocol) definito in IPv4. Il server mantiene aggiornato un database nel quale sono memorizzate le informazioni circa gli indirizzi già assegnati. Questo tipo di autoconfigurazione è consigliata per siti di grandi dimensioni in quanto si ottiene una migliore utilizzazione degli indirizzi ed una maggiore garanzia di sicurezza.

IPv6 introduce un nuovo tipo di configurazione automatica che si attiva non appena viene abilitata l'interfaccia ed ha il grosso vantaggio di non richiedere l'intervento di server appositi, cosicché non è più necessario configurare i nodi con l'indirizzo del server. Questo nuovo meccanismo è chiamato autoconfigurazione stateless e fa parte del protocollo di Neighbor Discovery, il quale si basa sulle informazioni pubblicizzate da ogni router ai propri vicini. Esso è un protocollo di base per IPv6 e verrà descritto approfonditamente in un paragrafo dedicato.

Autoconfigurazione dei router

Alla base del protocollo di Neighbor Discovery e dei meccanismi per la configurazione automatica delle stazioni vi sono i messaggi inviati dai router: occorre quindi che essi siano aggiornati per primi in caso di cambiamenti all'interno di un sito. Mantenere aggiornato un router vuol dire fare in modo che esso abbia la conoscenza esatta dell'organizzazione della sottorete alla quale è collegato e ciò vuol dire assegnare i prefissi di rete corretti a ogni link sul quale il router ha una interfaccia.

La gestione manuale dei prefissi è molto onerosa, sia per le dimensioni degli indirizzi IPv6 sia per la frequenza con cui può essere necessario rinumerare un sito IPv6. Per questo è in via di definizione il protocollo di Router Renumbering (RR). Questo è un nuovo meccanismo di ICMPv6 che permette di configurare in modo automatico i prefissi sui router, attraverso lo scambio di pacchetti il cui formato generale è riportato in figura 27.


Figura 27 - Messaggio di Router Renumbering.

ICMPv6 assegna a RR un valore per type pari a 138. I tipi di messaggi definiti sono due e sono distinti dal contenuto del campo code: zero per i messaggi Command e uno per quelli Result.
Il message body di un RR Command contiene una sequenza di Prefix Control Operation (PCO ); in ognuno di essi è specificata un'operazione (ADD, CHANGE o SET GLOBAL), un Match-Prefix e zero o più Use-Prefix.

Un router che riceve un RR Command, processa ogni PCO in sequenza, controllando per ognuna delle sue interfacce se vi è una corrispondenza tra il loro indirizzo e un Match-Prefix. In caso affermativo applica l'operazione specificata che può essere di aggiunta, rimozione o cambio prefisso. Il campo Use-Prefix indica i prefissi da aggiungere e/o sostituire. In seguito il router invia al mittente un messaggio di RR Result in cui riporta l'esito dell'operazione.
A causa delle potenzialità di questo meccanismo sono stati aggiunti i campi Authentication Data e sequence number per tutelarsi da repliche di pacchetti che possono avvenire soprattutto in seguito alla frammentazione o contro cambi di prefissi da parte di chi non ne ha l'autorizzazione.
L'interesse per il protocollo di Router Renumbering è molto vivo per cui si sta lavorando affinché diventi al più presto un proposed standard.

Autoconfigurazione del DNS

Le applicazioni manipolano in genere nomi di dominio piuttosto che indirizzi numerici per facilitare l'interfacciamento con l'uomo. Un indirizzo è ottenuto attraverso una ricerca nel Domain Name System (DNS), il database distribuito che memorizza diverse associazioni nome-indirizzo per ogni dominio di Internet.
Gli indirizzi sono memorizzati in strutture dati chiamate "resource records" e identificate dal tipo: gli indirizzi IPv4 sono memorizzati in record di tipo A che perciò contengono indirizzi di 32 bit. Per IPv6 è stato definito il nuovo tipo AAAA che contiene indirizzi su 128 bit.

L'aggiornamento del DNS è un'operazione onerosa e lunga in quanto si tratta di manipolare ogni record il cui contenuto deve essere modificato e poi occorre propagare tale informazione dal server primario agli altri server di rete. In IPv6 tale operazione è resa ancora più faticosa dalle dimensioni dell'indirizzo e dal fatto che le rinumerazioni sono più frequenti: diventa basilare perciò pensare a un meccanismo per la configurazione e l'aggiornamento automatico del DNS.


Figura 28 - Formato record A6.

Al momento non vi è ancora un protocollo disponibile che consenta l'autoconfigurazione del DNS, però si è definito un nuovo tipo di record, chiamato A6 e mostrato in figura 28, che se usato al posto di quello AAAA faciliterà l'adozione di un meccanismo automatico per la gestione del DNS.

Il record A6 contiene tre campi: la lunghezza del prefisso, un suffisso di un indirizzo IPv6 e il nome di dominio del prefisso. Per capire come queste informazioni possano essere utilizzate per ottenere un indirizzo di 128 bit si consideri il caso di un host appartenente al sito X che si poggia al provider A. Usando i record AAAA si dovrebbe memorizzare un'associazione del tipo:

hostIPv6.sito-X.providerA.net <-> 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0

usando un solo record. Con i record A6 invece si devono creare le seguenti associazioni:

hostIPv6 <-> 64 :: 1234:5678:9ABC:DEF0 sito-X
sito-X <-> 48 : 00C1:CA11:0001:: providerA.net
providerA.net <-> 0 2345::

Per ottenere l'indirizzo IPv6 di tale host un client DNS deve acquisire la catena completa dei tre record A6. L'ultimo record della catena si riconosce dalla lunghezza nulla del prefisso.
Il vantaggio di un sistema del tipo appena descritto è la semplicità dell'aggiornamento in caso di rinumerazione dei siti poiché e sufficiente modificare il record relativo al sito ( es: sito-X), ma non occorre toccare i record relativi alle sue stazioni.
Per la risoluzione inversa (cioè dato l'indirizzo ricavare il nome), è stato definito il dominio IP6.INT. Un indirizzo IPv6 è rappresentato come una sequenza di cifre separate da un punto e codificate in ordine inverso. Esempio:

4321:0:1:2:3:4:567:89AB
   diventa
B.A.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.1.2.3.4.IP6.INT

Questa modalità di rappresentazione richiede che sia memorizzato un record per ogni indirizzo assegnato a un'interfaccia. Così facendo però si complica notevolmente il problema dell'aggiornamento e questo e ancor più grave che nel caso precedente poiché il numero delle richieste di risoluzione inversa è maggiore delle richieste di risoluzione diretta. La soluzione proposta è quella di usare un meccanismo recursivo analogo a quello appena visto per il record A6. Nel caso esaminato in precedenza, per esempio, ci sarà un record IP6.INT contenente il prefisso del provider, uno quello assegnato al sito e uno contenente l'indirizzo assegnato alla stazione scritto in un formato del tipo:

0.F.E.D.C.B.A.9.8.7.6.5.4.3.2.1.sito-X.providerA.net.IP6.INT

Autoconfigurazione dei servizi

Tradizionalmente, per poter usufruire dei servizi disponibili in rete, gli utenti devono conoscere almeno il nome dell'host di rete sul quale questi sono installati. Ciò non rispetta pienamente il paradigma plug & play in quanto esso prevede la possibilità di utilizzare tutto ciò che la rete offre senza conoscere nulla circa la sua configurazione.
Per questo motivo è stato pensato il protocollo di Service Location (SLP), il quale fornisce una struttura flessibile e scalabile affinché gli host abbiano accesso all'informazione circa l'esistenza, la locazione e la configurazione di servizi di rete.
SLP elimina la necessità per un utente di conoscere il nome di una stazione della rete che supporta il servizio desiderato, ma è sufficiente che sappia descriverne il tipo e un insieme di attributi e, in base a tale descrizione, SLP risolve l'indirizzo di rete del servizio per l'utente. Oltre a ciò offre anche un meccanismo di configurazione dinamica per le applicazioni in reti locali.

Questo protocollo è ancora in corso di standardizzazione sia per IPv4 sia per IPv6. Il funzionamento è identico per entrambi e si basa sullo scambio di messaggi da parte di tre processi : User Agent, Service Agent (SA) e Directory Agent (DA).
User Agent (UA) è un processo che lavora sulla macchina di un utente con lo scopo di effettuare la richiesta del servizio inviando un messaggio di Service Request, costruito in base alle esigenze dell'applicazione di utente. Tale richiesta può essere fatta direttamente al SA usando un messaggio multicast oppure in unicast a un DA.
Nel primo caso risponderà il Service Agent interessato, che è posto sulla macchina dotata di quel servizio, con un messaggio di Reply inviato all'indirizzo unicast dell'UA che ha fatto la richiesta.
Directory Agent è un processo che può essere posto su una qualsiasi macchina della rete e funziona come una memoria cache, in cui sono memorizzate le informazioni relative ai Service Agent e ai servizi da loro annunciati. L'User Agent può così usare messaggi unicast indirizzati a un particolare DA per ottenere le informazioni cercate.
La presenza di un Directory Agent è rilevata dagli altri due processi sia al loro avvio che tramite l'invio periodico di messaggi multicast del tipo Service Request cui il DA risponde con un Advertisement inviato sempre in multicast. E´ importante che i SA sappiano della presenza dei DA in quanto le informazioni che questi memorizzano sono fornite proprio dai SA e sono sempre questi processi che le mantengono aggiornate.
I servizi in genere sono raggruppati per tipo usando una particolare etichetta detta scope string. Essa può indicare una locazione, un gruppo amministrativo o altre caratteristiche ed è sempre assegnata ai SA e DA. In questi modo fornendo una scope string anche all'UA è possibile limitarne il campo di ricerca.
Le differenze tra il protocollo SLP in IPv4 da quello per IPv6 sono soprattutto a livello implementativo e nascono dalle differenze tra i due protocolli, quali per esempio il formato degli indirizzi.


previous next