IPv6 – 6: Neighbor Solicitation Stateless Address Auto Configuration (SLAAC)

Le dimensioni di un indirizzo IPv6 lo rendono poco maneggiabile per l’amministratore. Una configurazione automatica di indirizzi unicast (anche pubblici, raggiungibili da Internet) è una caratteristica estremamente utile. Per poterla ottenere in automatico IPv6 si appoggia pesantemente ad ICMPv6, ed in particolare ai messaggi di Router Solicitation e Advertisement, che abbiamo visto nella sezione 5 e ai messaggi di Neighbor Solicitation e Discovery che vediamo ora.

Neighbor solicitation e Neighbor Advertisement

Questi due messaggi servono a scoprire se un nodo è raggiungibile (sia per verificarne se “il partner” esiste sia per verificare se il proprio indirizzo è già in uso), e per conoscere l’indirizzo link layer di un nodo (ruolo svolto da ARP in IPv4).  Un messaggio di Neighbor Solicitation (NS) può essere inviato multicast, per risolvere un indirizzo, o unicast se un nodo desidera verificare la raggiungibiltà e l’esistenza di un nodo vicino.

Un messaggio di Neighbor Solicitation ha questo formato:

  • Source address: contiene un indirizzo assegnato all’interfaccia; se il nodo sta effettuando Duplicate Address Detection o SLAAC conterrà l’indirizzo nullo.
  • Hop limit: 255
  • Type: 135
  • Code: 0
  • Checksum: controllo di errore
  • Target address: usato in Neighbor Advertisement e Redirect. Non può essere un indirizzo di multicast.

Un messaggio di Neighbor Advertisement ha questo formato:

  • Source address: contiene un indirizzo assegnato all’interfaccia; se il nodo sta effettuando Duplicate Address Detection o SLAAC conterrà l’indirizzo nullo.
  • Hop limit: 255
  • Type: 136
  • Code: 0
  • Checksum: controllo di errore
  • Reserved: 4 byte a 0, con l’eccezione dei primi tre bit vengono usati per indicare
    • R: router flag
    • S: solicited flag
    • O: override flag
  • Target address: l’indirizzo IP del nodo oggetto della solicitation. Non può essere un indirizzo di multicast

Opzioni: Target Link Layer Address.

Se il bit R è settato, il mittente è un router.

Se il Bit S è settato, il messaggio è la risposta ad una Neighbor Solicitation.

O settato indica che la risposta deve sovrascrivere ogni link layer address in cache.

Stateless address auto configuration SLAAC

L’obiettivo della SLAAC è quello di evitare l’uso di server DHCP e permettere ad un nodo di configurarsi completamente ed in maniera automatica. In questo modo la connettività può essere estesa ad apparati home, come televisori, elettrodomestici, sensori, etc. senza che sia necessario avere altro che un router IPv6 opportuamente configurato.  In ambito enterprise esigenze diverse, prevalentemente di tracciabilità delle risorse, possono rendere necessario l’utilizzo di un server DHCP.

Come funziona SLAAC:

1. All’avvio del sistema il nodo inizia l’autoconfigurazione, ottenendo un token di interfaccia dall’hardware (ad esempio il Mac address della scheda, ma può essere anche un numero casuale).
2. Il nodo crea un primo indirizzo link-local unicast (vale a dire un indirizzo che ha scope esclusivamente locale) combinando il prefisso  (FE80::/10) con il token.
3. A questo punto il nodo prova  a inviare un messaggio di Neighbor Solicitation Message proprio con l’indirizzo appena generato, per verificare se è unico. Se ottiene risposta positiva da qualche vicino, vale a dire se questo indirizzo è già usato, il processo di autoconfigurazione si arresta, ed è necessario procedere con la configurazione manuale. (In IPv4 l’host avrebbe emesso una query ARP con il proprio indirizzo per verificarne l’unicità).

4. Se tutto va bene, vale a dire se l’IP address è unico, il nodo assegna questo primo indirizzo all’interfaccia. Abbiamo dunque un nodo con indirizzo locale, ma ancora nessuna connettività globale. Per ottenerla, il nodo cerca quali sono i gateway della propria rete. Questo viene fatto inviando un messaggio di router solicitation all’indirizzo multicast di tutti  i router come definito da RFC4291 (FF02::2).

5. Se sono presenti dei router sul link, rispondono con un proprio router advertisement.  Nel caso non dovessero arrivare comunicazioni, il nodo prova a configurarsi emettendo delle richieste DHCPv6. Se neanche il DHCP server dovesse rispondere, il nodo mantiene il proprio indirizzo ed effettua solo traffico link local (con i nodi sulla stessa rete).

6. Se invece il nodo riceve dei router advertisement, vengono valutati diversi elementi del messaggio:
M flag: Managed Address Configuration – indica che il nodo deve ottenere un indirizzo via DHCP
O flag: Other stateful configuration – indica che DHCP deve essere usato per ottenere altri parametri di configurazione
– Prefix option: se l’opzione è settata con il bit A (autonomous
address configuration flag) alto, il prefisso viene usato per la stateless autoconfiguration.

In questo caso, il prefisso viene letto dal router advertisement ed usato per generare la parte rete dell’indirizzo locale del nodo. In sostanza l’indirizzo del nodo diventa la concatenazione del prefisso assegnato dal router e del token di interfaccia generato inizialmente.

A questo punto il nodo si è configurato completamente. Continua ad osservare i router advertisement periodici per verificare che non ci siano cambiamenti.
E’ possibile anche usare (O option settata) un server HDCP per avere le altre opzioni di rete, come ad esempio i DNS da utilizzare.

Un indirizzo IPv ha una certa durata, indicata dal tempo di vita del prefix assegnato dal router nel router advertisement, al termine della quale diventa un indirizzo non valido.  Nel corso della sua vita, un indirizzo IP passa attraverso diversi stati:

Tentative address

E’ un indirizzo che non è stato ancora verificato mediante DAD. Viene usato solo per ND nel processo di autoconfigurazione.

Preferred address

Un indirizzo assegnato all’interfaccia e che può essere utilizzato

Deprecated address 

Un indirizzo che può essere utilizzato, ma sarebbe meglio non usare, ad esempio perché la sua vita sta per terminare.

Optimistic address 

Un indirizzo utilizzabile e assegnato all’interfaccia, anche se DAD non è ancora concluso. L’obiettivo dell’introduzione di questo stato è quello di minimizzare i ritardi di configurazione dell’interfaccia (RFC 4429).

Utilizzando il sito, accetti l'utilizzo dei cookie da parte nostra. Usiamo i cookies per ragioni tecniche. Teniamo in alta considerazione la tua privacy.

Questo sito utilizza i cookie per fonire la migliore esperienza di navigazione possibile. Continuando a utilizzare questo sito senza modificare le impostazioni dei cookie o clicchi su "Accetta" permetti al loro utilizzo.

Chiudi