IPv6

Blog post description.

5/21/20238 min read

Il Problema del NAT

Abbiamo già visto che l'IPv4 non ha un numero sufficiente di indirizzi assegnabili agli host e che è stato ideato l'IPv6 per colmare le lacune dell'IPv4 ed il NAT, che viene usato come soluzione momentanea fino a che non ci sarà la migrazione completa all'IPv6.
Tuttavia il NAT non è perfetto: andiamo a vedere ora un esempio in cui il NAT non è sufficiente.

Nel nostro esempio abbiamo due aziende (A e B) che fanno molti affare tra loro ed hanno quindi deciso di avere dei telefoni IP per risparmiare. Entrambe le compagnie hanno il loro Call Manager (che io ho abbreviato in CM, ma il dispositivo è di Cisco e si chiama Cisco Unified Communications Manager) che controlla il relativo telefono VoIP e che punta verso l'altro telefono.
Vediamo ora come funziona il tutto per capire meglio perché il NAT non è la soluzione a tutti i problemi e perché ci vuole l'IPv6.
Immaginiamo che qualcuno all'azienda A voglia chiamare qualcuno all'azienda B: il telefono A ha l'indirizzo IP di 10.0.0.10 che viene "NATtato" in 203.0.113.10. A questo punto, visto che i telefoni VoIP non sono così intelligenti da prender decisioni, il telefono A deve contattare il suo CM (CM-A).
L'utente alla compagnia A digita "11-2001", il che manda un segnale al CM-A dicendo "vorrei chiamare l'11-2001".
Questo segnale parte dall'indirizzo 10.0.0.10 e arriva all'indirizzo 10.0.0.100 del CM-A, siccome tutto sta avvenendo all'interno della rete dell'azienda A per ora non abbiamo problemi.
Il CM-A controlla nel suo registro (impostato dall'amministratore) e vede che ogni chiamata verso "11-XXXX" deve essere reindirizzata verso il CM-B, raggiungibile all'indirizzo IP pubblico di 203.0.113.20.
Quindi il CM-A manda un segnale al CM-B dicendo "Hey, c'è una chiamata per 11-2001 e viene dal telefono 10.0.0.10. Questo traffico viene dall'IP del CM-A a 10.0.0.100 e si dirige verso il CM-B a 203.0.113.20.
Quando il traffico raggiunge il router A, questo NATta l'IP 10.0.0.100 nell'indirizzo IP pubblico 203.0.113.3, perché abbiamo impostato una regola di NAT statico sul router A.
Il traffico viene quindi ricevuto dal router B che NATta l'indirizzo di destinazione 203.0.113.20 all'indirizzo IP privato di 10.0.10.100 perché anche la Compagnia B ha impostato sul suo router una regola di NAT statico per il suo CM.
Il segnale arriva così al CM-B che conosce che il numero 11-2001 è disponibile all'indirizzo IP 10.0.10.10 e quindi manda un messaggio al telefono B che serve a farlo suonare.
Un dipendente dell'azienda B sente il telefono suonare e alza la cornetta, il che genera un nuovo messaggio diretto verso il CM-B che indica che l'utente al telefono B ha alzato la cornetta e la chiamata è pronta per partire.
Il CM-B segnala al CM-A che "il dispositivo con numero 11-2001 è pronto per la chiamata e che il suo indirizzo è 10.0.10.10". Questo parte da 10.0.10.100 (CM-B) ed arriva a 203.0.113.3 (CM-A).
Il router B manda il traffico e, come prima, NATta l'indirizzo sorgente (10.0.10.100, indirizzo privato di CM-B) in 203.0.113.20. Il router A riceve il traffico e NATta 203.0.113.3 in 10.0.0.100.
A questo punto il CM-A manda un segnale al telefono A dicendo "Il telefono è pronto a trasmettere la tua voce direttamente a 10.0.10.10" e il CM-B pensa a far lo stesso col telefono B.
Qui abbiamo il nostro problema: affinché i due telefoni possano comunicare tra di loro hanno bisogno di avere indirizzi IP pubblici (10.0.10.10 e 10.0.10.100 funzionano solo internamente alle due aziende), ossia NATati da entrambi le parti. Tuttavia l'informazione si trova ad un livello più alto dei protocolli voce, a cui i telefoni IP non arrivano, quindi questi continueranno ad usare i loro indirizzi IP privati facendo così fallire la chiamata.


Per risolvere questo problema si possono usare dispositivi come i firewall di livello applicazione, che possono guardare cosa succede negli strati più alti del traffico e fare aggiustamenti.
Esistono anche altri metodi per risolvere il problema come l'utilizzo di server trasversali e server proxy, ma ciò che ci interessava in questa spiegazione era capire che il NAT può interrompere il normale funzionamento del protocollo IP e anche quello delle applicazioni che usano indirizzi o porte nei livelli più alti dell'OSI.

Abbiamo visto come sarebbe molto bello (e comodo) se ci fossero abbastanza indirizzi IP per tutti i dispositivi del mondo.
Ecco che entra in scena l'IPv6 che usa 128 bit invece dei 32 dell'IPv4. Questo permette di avere molti più indirizzi disponibili, ma ci sono anche altre migliorie riguardo la sicurezza e la possibilità per un host di mantenere lo stesso indirizzo pur muovendosi in posti fisicamente distanti (ossia avere lo stesso indirizzo IP che tu sia in Italia, in Spagna o in qualunque altro stato).
E' possibile usare contemporaneamente sia l'IPv4 sia l'IPv6 (configurazione dual stack): se un'applicazione manda del traffico ad un indirizzo IPv4 allora userà l'IPv4, ma se manda del traffico ad un indirizzo IPv6 allora userà l'IPv6.

Il Format dell'IPv6

Come abbiamo già visto l'IPv6 usa un indirizzo a 128 bit che viene scritto nel formato X:X:X:X:X:X:X:X, dove ogni X è un campo esadecimale a 16 bit (i valori sono 0-9, A-F).
Esempio: 2001:0DB8:0000:0001:0000:0000:0000:0001

Negli indirizzi IPv4 si hanno 32 bit con formato X.X.X.X dove ogni X viene chiamata "ottetto" e formata da 8 bit.
Negli indirizzi IPv6, invece, non si ha un nome officiale per ogni "X", vengono di solito chiamati segmenti, quartetti o pezzi.

Abbiamo visto quanto sia lungo un indirizzo IPv6, ma esistono alcuni modi per renderlo più corto: "l'address shortening" è una convenzione standard e supportata dai venditori di tutti i dispositivi.
Secondo questo metodo ogni zero iniziale di ogni segmento può essere rimosso, il nostro 2001:0DB8:0000:0001:0000:0000:0000:0001
diventerà quindi
2001:DB8:0:1:0:0:0:1

Per abbreviare ancora di più si può sostituire un segmento se sono presenti solo degli zero e scriverlo semplicemente come "::".

Indirizzi Global Unicast IPv6

Questo tipo di indirizzi sono simili agli indirizzi IPv4 pubblici, vengono infatti assegnati ad un host individuale e possono essere raggiunti globalmente (a meno che non siano bloccati da una Policy di sicurezza come un su un firewall)e vengono assegnati dal range 2000::/3.
Un comune range di IP che può ricevere una compagnia è un /48, come ad esempio 2001:10:10::/48, ma è comunque possibile dare un blocco più grande o più piccolo a secondo della grandezza della compagnia.

Gli standard IPv6 prevedono che gli indirizzi assegnati ad host individuali abbiano una maschera di /64.
Visto che gli indirizzi IPv6 sono lunghi 128 bit, la maschera /64 divide a metà per l'identificatore di rete e quello di host.

Se ad una compagnia gli viene assegnato un indirizzo /48 e usa un identificatore di host di /64, allora rimangono 16 bits che l'azienda può assegnare alle sue sottoreti interne (128 - 48 - 64 = 16).
Per esempio, se ad un'azienda venisse assegnato 2001:10:10::/48, potrebbe assegnare le sottoreti da 2001:10:10:0::/64 a 2001:10:10:FFFF::/64 alle sottoreti interne.
16 bits = 65535 sottoreti possibili
64 bits rimasti (128 - 48 - 16) = moltissimi host
Vediamo la rete del nostro esempio:

Indirizzi EUI-64

Un router Cisco può generare indirizzi IPv6 completi per sé stesso dopo che gli è stato detto quale interfaccia e quale rete /64 usare.
La porzione di host dell'indirizzo è derivato dall'indirizzo MAC dell'interfaccia, che è ovviamente unico globalmente.
Tuttavia gli indirizzi MAC hanno 48 bit mentre l'identificatore di host in questo caso è /64.
Dobbiamo quindi iniettare "FF:FE" nella metà dell'indirizzo MAC per portarlo a 64 bit. Inoltre, il settimo bit viene invertito.

Configurazione:

R1(config)#int f0/0
R1(config-if)#ipv6 address 2001:db8:0:1::/64 eui-64
R1(config)#int f2/0
R1(config-if)#ipv6 address 2001:db8:0::/64 eui-64

Indirizzi Unique Local

Questo tipo di indirizzi è simile agli indirizzi privati IPv4 dell'RFC 1918, quindi non sono raggiungibili pubblicamente e vengono assegnati dal range FC00::/7.
Agli host dovrebbero venir assegnati indirizzi /64.

Indirizzi Link Local

Questi indirizzi sono validi solo per le comunicazioni su quel link, vengono assegnati dal range FE80::/10 - FEB0::/10 e agli host dovrebbero venir assegnati indirizzi /64.

Connettività Link Local

Come possiamo vedere A, B e C hanno connettività a l'un l'altro tramite gli indirizzi link local FE80::1, FE80::2 e FE80::3 sullo stesso segmento.
B e D sono connessi l'un l'altro tramite gli indirizzi link local FE80::4 e FE80::5 sullo stesso segmento.
FE80::1, FE80::2 e FE80::3 non sono connessi né a FE80::4 né a FE80::5.
Gli indirizzi link local possono essere usati per comunicazioni che non dovrebbero essere inoltrate oltre al link locale, come i pacchetti di aggiornamento ed hello dei protocolli di routing.
Sono obbligatori sulle interfacce dei router Cisco con Ipv6 abilitato e gli indirizzi link local sono generati automaticamente con indirizzi EUI-64 su questo tipo di router.
Gli indirizzi EUI-64 possono essere sovrascritti tramite una configurazione manuale.

Configurare un indirizzi global unicast attiva IPv6 sull'interfaccia:

R1(config)#ipv6 unicast-routing
R1(config)#int f0/0
R1(config-if)#ipv6 add 2001:db8:0:0::1/64
R1(config-if)#int f2/0
R1(config-if)#ipv6 add 2001:db8:0:0::1/64

Configurazione manuale degli indirizzi link local

Come abbiamo visto gli indirizzi link local sono validi solo sul link locale quindi è possibile utilizzare lo stesso indirizzo su più interfacce:

R1(config)#int f0/0
R1(config-if)#ipv6 address fe80::1 link-local
R1(config-if)#int f2/0
R1(config-if)#ipv6 address fe80::1 link-local

Indirizzi multipli con IPv4 e IPv6

Nonostante non sia una procedura molto comune è possibile assegnare alla stessa interfaccia due indirizzi IPv4, ma è necessario utilizzare la parola-chiave "secondary":

R1(config)#int f0/0
R1(config-if)#ip address 192.168.10.1 255.255.255.0
R1(config-if)#ip address 172.16.0.1 255.255.255.0 secondary

E' invece possibile avere più indirizzi IPv6 senza problemi sulla stessa interfaccia:

R1(config)#int f0/0
R1(config-if)#ipv6 address FE80::1 link-local
R1(config-if)#ipv6 add 2001:db8:0:0::1/64
R1(config-if)#ipv6 add 2001:db8:0:1::1/64

Indirizzamento (Routing) con IPv6

L'indirizzamento dell'IPv6 funziona allo stesso modo del v4, ma i processi sono separati: ci sono tabelle di indirizzamento IPv4 e IPv6.
Se un router riceve un pacchetto IPv4, lo indirizzerà a seconda della tabella di routing IPv4 ed ugualmente accade con un pacchetto IPv6.
Le tabelle di routing vengono create allo stesso modo: tramite route statiche o attraverso protocolli dinamici di routing.

Protocolli di Routing che supportano IPv6


Le versione degli esistenti protocolli di routing IPv4 sono state aggiornate per supportare anche IPv6.
Le configurazioni e funzionamento sono molto simili alla loro controparte v4.
Ecco una lista dei protocolli di routing che supportano l'IPv6:

  • RIPng (RIP next generation)

  • EIGRP per IPv6

  • OPSFv3

  • IS-IS

  • MP-BGP4 (MultiProtocol BGP-4)

L'indirizzamento IPv4 è abilitato di default dai router Cisco con IOS, mentre l'indirizzamento IPv6 è disattivo.
Bisogna inserire il comando "ipv6 unicast-routing" per abilitarlo.
E' comunque possibile configurare indirizzi v6 su di un router senza il comando precedente per mandare e ricevere traffico IPv6 all'interno della sottorete, ma il router non riuscirà a comunicare con le reti esterne.

Verifica delle route IPv6 connesse

Le route locali hanno sempre una sottomaschera di /128 e mostrano l'indirizzo IP configurato sull'interfaccia.
Il comando per vedere le route connesse è "show ipv6 route".

Routing

Se un router riceve traffico per un router a cui non è direttamente connesso, deve sapere come arrivarci per poter instradare il traffico.
Solitamente un amministratore può aggiungere manualmente una route statica alla destinazione, o un router può impararla attraverso un protocollo di routing.