WEBVTT

00:00.090 --> 00:01.050
Istruttore: In questa

00:01.050 --> 00:04.200
lezione introdurremo i concetti relativi all'IPv6,

00:04.200 --> 00:06.600
o Protocollo Internet versione 6.

00:06.600 --> 00:07.740
Finora abbiamo parlato

00:07.740 --> 00:10.230
solo di IPv4, ma uno dei problemi che

00:10.230 --> 00:13.020
abbiamo con l'IPv4 è che il suo spazio di

00:13.020 --> 00:15.510
indirizzi è limitato.

00:15.510 --> 00:17.370
Questo perché i bit che compongono un

00:17.370 --> 00:19.380
indirizzo IPv4 sono solo 32, mentre i bit

00:19.380 --> 00:23.070
che lo compongono sono solo 4. 2 miliardi di combinazioni di indirizzi possibili.

00:23.070 --> 00:26.430
Ora, ne conosco 4. 2 miliardi sembrano un sacco di IP,

00:26.430 --> 00:28.950
ma quando abbiamo eliminato intere porzioni di cose,

00:28.950 --> 00:32.160
come gli indirizzi APIPA, gli indirizzi di host locali, gli IP privati,

00:32.160 --> 00:34.770
e poi c'è stata un'enorme quantità di sprechi prima ancora

00:34.770 --> 00:36.720
di iniziare a usare il subnetting, questo

00:36.720 --> 00:38.670
ha portato a un grosso problema, e abbiamo

00:38.670 --> 00:41.040
iniziato a esaurire gli indirizzi di rete all'interno

00:41.040 --> 00:42.810
dell'IPv4.

00:42.810 --> 00:46.860
Questo fenomeno è noto come esaurimento degli indirizzi ed è reale.

00:46.860 --> 00:49.260
Infatti, nel novembre 2019, il RIPE NCC,

00:49.260 --> 00:51.810
il Registro regionale di Internet per l'Europa,

00:51.810 --> 00:56.160
l'Asia occidentale e l'ex URSS, e la NASA, hanno già esaurito l'intero

00:56.160 --> 00:59.130
pool di indirizzi IPv4.

00:59.130 --> 01:01.770
Fortunatamente, però, l'Internet

01:01.770 --> 01:04.740
Engineering Task Force, o IETF, aveva già

01:04.740 --> 01:06.600
iniziato a guardare al futuro

01:06.600 --> 01:09.690
e aveva sviluppato l'IPv6 come standard già

01:09.690 --> 01:13.380
nel 1995, con un RFC che documentava la visione dell'IPv6,

01:13.380 --> 01:17.790
definito IP Next Generation o IPNG.

01:17.790 --> 01:22.790
Ora vedete, l'IPv6 è in realtà un enorme miglioramento rispetto all'IPv4 in termini

01:22.860 --> 01:25.290
di numero di indirizzi disponibili.

01:25.290 --> 01:28.710
Invece di utilizzare un indirizzo a 32 bit come nell'IPv4,

01:28.710 --> 01:32.100
l'IPv6 utilizzerà un indirizzo a 128 bit.

01:32.100 --> 01:35.490
In questo modo si otterrà uno spazio di indirizzi molto più ampio.

01:35.490 --> 01:37.620
In effetti, vi darà la possibilità

01:37.620 --> 01:41.430
di 340 undecilioni di indirizzi IP.

01:41.430 --> 01:42.930
Si tratta di un numero sufficiente

01:42.930 --> 01:45.930
di indirizzi IP per ogni uomo, donna e bambino del pianeta.

01:45.930 --> 01:48.540
Si tratta di due alla 128esima potenza.

01:48.540 --> 01:51.300
In realtà, ci sono molti, molti indirizzi IP per ogni

01:51.300 --> 01:53.730
uomo, donna e bambino del pianeta, perché ci

01:53.730 --> 01:56.250
sono così tanti indirizzi IP disponibili.

01:56.250 --> 01:57.960
Ora, potreste chiedervi:

01:57.960 --> 02:01.230
"Ehi, siamo passati dall'IPv4 all'IPv6".

02:01.230 --> 02:03.090
Cosa è successo alla versione 5?

02:03.090 --> 02:05.370
Perché siamo passati direttamente alla versione 6?

02:05.370 --> 02:09.180
La versione 5 è stata creata, ma non è mai stata adottata come protocollo

02:09.180 --> 02:11.190
o standard ufficiale.

02:11.190 --> 02:13.350
E quindi non è mai entrato in produzione.

02:13.350 --> 02:14.820
Invece, molti dei concetti sviluppati

02:14.820 --> 02:16.350
con la versione 5, perché si trattava

02:16.350 --> 02:17.970
di un protocollo sperimentale, sono

02:17.970 --> 02:19.920
stati inseriti nell'IPv6 quando è diventato

02:19.920 --> 02:21.870
uno standard ufficiale.

02:21.870 --> 02:25.650
Parliamo quindi dei vantaggi dell'IPv6.

02:25.650 --> 02:26.910
Uno dei maggiori vantaggi

02:26.910 --> 02:28.890
è lo spazio di indirizzamento molto più

02:28.890 --> 02:31.350
ampio, grazie agli indirizzi a 128 bit.

02:31.350 --> 02:32.460
Inoltre, l'IPv6 ha

02:32.460 --> 02:35.160
aumentato l'efficienza delle nostre reti eliminando

02:35.160 --> 02:38.730
il tipo di flusso di dati broadcast dell'IPv4.

02:38.730 --> 02:41.250
Ora, l'IPv6 è anche più sicuro, perché lo standard

02:41.250 --> 02:44.010
IPv6 non prevede la frammentazione dei pacchetti

02:44.010 --> 02:46.050
o dei datagrammi.

02:46.050 --> 02:48.150
Inoltre, non esiste un'unità massima di trasmissione

02:48.150 --> 02:51.330
per la scoperta all'interno di ogni sessione, a differenza di IPv4 che

02:51.330 --> 02:54.870
contiene un MTU con una certa dimensione per ogni pacchetto.

02:54.870 --> 02:57.030
In IPv4, se si invia un pacchetto più grande

02:57.030 --> 02:59.820
della dimensione massima dell'unità di trasmissione,

02:59.820 --> 03:01.080
questo viene frammentato

03:01.080 --> 03:02.400
e inviato sulla rete.

03:02.400 --> 03:04.110
E poi, una volta giunto a destinazione,

03:04.110 --> 03:05.970
sarebbe stato riassemblato e letto.

03:05.970 --> 03:07.650
Si trattava in realtà di un rischio per la sicurezza.

03:07.650 --> 03:09.540
Inoltre, richiedeva un'elaborazione supplementare

03:09.540 --> 03:11.460
e poteva effettivamente rallentare le reti perché

03:11.460 --> 03:13.920
diventava un modo molto inefficiente di fare le cose nelle nostre

03:13.920 --> 03:15.120
reti moderne con velocità di connessione

03:15.120 --> 03:17.070
a Internet più elevate.

03:17.070 --> 03:19.830
Con l'IPv6, quindi, si è deciso di eliminare completamente

03:19.830 --> 03:21.900
la frammentazione.

03:21.900 --> 03:24.480
Ora, oltre a fornire tutti questi nuovi vantaggi,

03:24.480 --> 03:26.970
i creatori dell'IPv6 sono stati molto intelligenti

03:26.970 --> 03:30.690
e hanno capito che l'IPv6, per essere abbracciato e accettato pienamente,

03:30.690 --> 03:33.630
avrebbe dovuto essere retrocompatibile con l'IPv4

03:33.630 --> 03:38.630
e consentire la coesistenza di IPv6 e IPv4 sulla stessa rete.

03:38.700 --> 03:41.490
Dopo tutto, era già la fine degli anni '90 quando

03:41.490 --> 03:43.950
l'IPv6 è stato sviluppato e rilasciato e molte

03:43.950 --> 03:45.270
reti di computer erano

03:45.270 --> 03:47.490
già presenti in tutto il mondo.

03:47.490 --> 03:48.900
Non sarebbe quindi possibile

03:48.900 --> 03:51.960
cambiare tutto in un solo giorno.

03:51.960 --> 03:53.490
Pensate all'attuale migrazione

03:53.490 --> 03:55.170
dai veicoli a gas a quelli

03:55.170 --> 03:56.730
elettrici.

03:56.730 --> 03:58.920
Ciò avverrà per tutti gli

03:58.920 --> 04:00.420
anni 2020 e 2030.

04:00.420 --> 04:02.970
Ora, sarebbe impossibile dire: "Ehi,

04:02.970 --> 04:05.850
il 1° gennaio 2025 nessuno potrà più utilizzare

04:05.850 --> 04:07.710
veicoli a gas".

04:07.710 --> 04:08.700
A partire da quella data

04:08.700 --> 04:11.010
saranno tutti sostituiti da veicoli elettrici.

04:11.010 --> 04:12.180
Se un governo provasse a farlo,

04:12.180 --> 04:14.160
probabilmente si troverebbe per le mani una rivoluzione,

04:14.160 --> 04:17.190
perché molte persone possiedono già auto a gas e hanno speso una tonnellata

04:17.190 --> 04:19.890
di denaro e di investimenti per quelle auto e per le infrastrutture

04:19.890 --> 04:21.900
che le supportano.

04:21.900 --> 04:24.480
Per questo motivo, non sostituiremo semplicemente tutte

04:24.480 --> 04:26.250
le auto a gas da un giorno all'altro.

04:26.250 --> 04:28.680
Ci sarà invece una lenta transizione dall'alimentazione

04:28.680 --> 04:32.130
a gas a quella elettrica, che si protrarrà fino al 2030 o forse al 2040,

04:32.130 --> 04:34.890
quando un numero sempre maggiore di auto nuove vendute

04:34.890 --> 04:37.050
nel mondo sarà venduto come elettrico e si smetterà

04:37.050 --> 04:39.390
di vendere veicoli a gas.

04:39.390 --> 04:42.900
La stessa cosa sta accadendo con l'IPv6.

04:42.900 --> 04:47.010
Quindi l'IPv6 consente la coesistenza di IPv4 e IPv6 sulle stesse

04:47.010 --> 04:49.140
reti e le apparecchiature che gestiscono

04:49.140 --> 04:51.360
queste reti diventano note come dual

04:51.360 --> 04:53.370
stack, il che significa semplicemente

04:53.370 --> 04:54.930
che possono eseguire simultaneamente

04:54.930 --> 04:58.200
i protocolli IPv4 e IPv6 sugli stessi dispositivi di

04:58.200 --> 05:01.080
rete.

05:01.080 --> 05:04.410
Con i dispositivi dual stack, se un client supporta IPv6, lo

05:04.410 --> 05:06.960
switch del router preferisce utilizzare IPv6

05:06.960 --> 05:08.760
e parlerà con questo metodo.

05:08.760 --> 05:11.370
Ora, se un dispositivo non è in grado di supportare

05:11.370 --> 05:13.080
l'IPv6, torna indietro e dice:

05:13.080 --> 05:16.380
"Ok, ti parlerò usando il vecchio protocollo IPv4".

05:16.380 --> 05:18.390
In questo modo, posso continuare a sostenerla.

05:18.390 --> 05:20.850
Un altro metodo che utilizziamo è il cosiddetto tunneling.

05:20.850 --> 05:24.780
Questo è il caso in cui l'IPv6 verrà inserito in un tunnel su un dispositivo IPv4.

05:24.780 --> 05:27.150
In questo modo i router IPv4 più vecchi possono

05:27.150 --> 05:29.580
continuare a trasportare il traffico IPv6.

05:29.580 --> 05:31.710
L'IPv6 sarà essenzialmente un tunnel

05:31.710 --> 05:34.860
come meccanismo per incapsulare i pacchetti IPv6 all'interno

05:34.860 --> 05:38.370
di intestazioni IPv4 e trasportare questi dati IPv6 attraverso

05:38.370 --> 05:40.320
i router IPv4 e altre infrastrutture

05:40.320 --> 05:42.480
già esistenti.

05:42.480 --> 05:44.640
A tal fine, crea un tunnel punto-punto

05:44.640 --> 05:46.380
tra la sorgente e la destinazione

05:46.380 --> 05:48.450
e poi incapsula le informazioni.

05:48.450 --> 05:51.630
Ciò consente ai client e ai server IPv6 isolati di comunicare

05:51.630 --> 05:53.310
senza dover aggiornare tutti i router

05:53.310 --> 05:55.620
e l'infrastruttura di switch che utilizzano

05:55.620 --> 05:59.040
ancora l'IPv4 che possono essere presenti tra loro.

05:59.040 --> 06:02.880
Ora, un giorno, potremmo assistere al completo ritiro dell'IPv4.

06:02.880 --> 06:05.070
Ma finora non è successo.

06:05.070 --> 06:07.440
E personalmente non sto trattenendo il fiato.

06:07.440 --> 06:08.670
Da alcuni articoli

06:08.670 --> 06:11.160
che ho letto, le previsioni dicono che l'IPv4

06:11.160 --> 06:14.340
rimarrà con noi almeno fino al 2040, quindi come tecnici

06:14.340 --> 06:17.430
di rete dovrete saper lavorare sia con l'IPv4 che

06:17.430 --> 06:20.640
con l'IPv6 per il prossimo futuro.

06:20.640 --> 06:24.120
Un altro vantaggio dell'IPv6 è l'intestazione semplificata.

06:24.120 --> 06:26.850
Quindi, invece dei 12 campi che avevamo nell'IPv4, abbiamo

06:26.850 --> 06:29.430
solo cinque campi nell'IPv6, il che rende l'intestazione

06:29.430 --> 06:30.960
più snella e molto più efficiente

06:30.960 --> 06:33.630
da inviare sulle nostre reti.

06:33.630 --> 06:35.370
Vi starete chiedendo: che

06:35.370 --> 06:37.920
aspetto ha un'intestazione IPv6?

06:37.920 --> 06:40.500
Ve lo mostrerò, ma non dovete memorizzarlo

06:40.500 --> 06:42.750
per l'esame.

06:42.750 --> 06:44.940
Invece, questo è solo per mostrare i diversi

06:44.940 --> 06:47.040
campi dell'IPv4, che è in alto, rispetto

06:47.040 --> 06:49.230
all'IPv6, che è in basso.

06:49.230 --> 06:51.240
Ora potete vedere quanto sia

06:51.240 --> 06:54.450
più semplice l'IPv6 rispetto all'IPv4.

06:54.450 --> 06:56.190
Bene, torniamo ad alcune cose

06:56.190 --> 06:58.170
che dovete capire per l'esame.

06:58.170 --> 07:01.590
Ad esempio, che aspetto ha un indirizzo IPv6?

07:01.590 --> 07:04.590
Ho già detto che la lunghezza è di 128 bit, il

07:04.590 --> 07:08.160
che significa che se lo scrivessimo in binario avrebbe

07:08.160 --> 07:09.600
128 uno o zero, e mi sembra

07:09.600 --> 07:13.410
una pessima idea, quindi non lo faremo.

07:13.410 --> 07:15.210
Ora, potremmo usare la notazione decimale

07:15.210 --> 07:16.680
punteggiata come nel caso dell'IPv4,

07:16.680 --> 07:19.020
ma ci sarebbero comunque molti ottetti da scrivere,

07:19.020 --> 07:23.670
perché avremmo bisogno di 16 ottetti per rappresentare tutti i 128 bit.

07:23.670 --> 07:25.380
Per risolvere questo problema,

07:25.380 --> 07:27.360
l'IETF ha deciso di utilizzare invece

07:27.360 --> 07:29.310
le cifre esadecimali.

07:29.310 --> 07:31.860
L'esadecimale è in base 16, come forse ricorderete

07:31.860 --> 07:33.150
dalle lezioni di algebra

07:33.150 --> 07:34.980
del liceo.

07:34.980 --> 07:36.210
Ora, in esadecimale, ogni

07:36.210 --> 07:38.760
cifra esadecimale è in realtà quattro bit.

07:38.760 --> 07:41.250
Questo ci permetterà di rappresentare un indirizzo IPv6

07:41.250 --> 07:43.710
combinando insieme quattro cifre esadecimali per formare

07:43.710 --> 07:45.780
quello che chiamiamo segmento.

07:45.780 --> 07:48.720
Ora, un segmento conterrà 16 bit.

07:48.720 --> 07:51.030
Questo è rappresentato da queste quattro cifre esadecimali.

07:51.030 --> 07:52.440
Poi aggiungeremo i due punti

07:52.440 --> 07:53.880
e continueremo ad aggiungere

07:53.880 --> 07:56.250
segmenti fino ad arrivare a 128 bit, il che richiederà

07:56.250 --> 07:57.900
otto segmenti, ognuno dei quali

07:57.900 --> 08:00.510
con quattro cifre esadecimali.

08:00.510 --> 08:03.510
In questo modo si ottiene un totale di 32 cifre esadecimali,

08:03.510 --> 08:05.460
che sono comunque piuttosto lunghe.

08:05.460 --> 08:09.330
Ora, con 128 bit rappresentati in un indirizzo IPv6, ciò significa

08:09.330 --> 08:12.810
che non avremo più di 32 cifre esadecimali all'interno di

08:12.810 --> 08:14.700
tutti questi segmenti.

08:14.700 --> 08:18.150
Perché ho detto che il totale di questi otto segmenti

08:18.150 --> 08:20.250
non deve superare le 32 cifre?

08:20.250 --> 08:22.800
Perché non dovrebbero essere solo 32 cifre

08:22.800 --> 08:25.710
esadecimali, dato che 32 cifre per quattro bit

08:25.710 --> 08:28.290
per cifra corrispondono a 128 bit?

08:28.290 --> 08:31.320
Questo perché l'IPv6 ci permette di utilizzare una

08:31.320 --> 08:33.450
stenografia per semplificare i nostri

08:33.450 --> 08:35.880
lunghissimi indirizzi IPv6.

08:35.880 --> 08:37.980
Ora, le regole della stenografia sono molto importanti

08:37.980 --> 08:40.650
perché su di esse si possono fare domande d'esame.

08:40.650 --> 08:43.020
Quindi, se si hanno quattro zeri per un segmento,

08:43.020 --> 08:45.360
è possibile inserire uno zero al posto di questi,

08:45.360 --> 08:47.310
eliminando gli zeri iniziali.

08:47.310 --> 08:50.790
Ad esempio, facciamo finta di avere un indirizzo

08:50.790 --> 08:55.790
IPv6 molto lungo, 2018:0000:0000:0000:0000:0000:4815:54ae.

09:04.470 --> 09:05.820
Utilizzando la regola semplice,

09:05.820 --> 09:08.490
posso sostituire tutti i segmenti che hanno più zeri con

09:08.490 --> 09:09.810
un singolo zero.

09:09.810 --> 09:14.810
Questo mi darebbe 2018:0:0:0:0:0:4815:54ae.

09:19.590 --> 09:22.680
Bene, in questo modo ho ridotto il numero di cifre

09:22.680 --> 09:26.790
esadecimali da 32 a solo 17, quindi la lunghezza è circa la metà.

09:26.790 --> 09:29.520
Stiamo migliorando, ma non mi fermerò qui.

09:29.520 --> 09:30.710
C'è un'altra regola che posso

09:30.710 --> 09:33.000
usare nel mondo della stenografia IPv6.

09:33.000 --> 09:35.280
Questa regola dice che se ci sono più segmenti

09:35.280 --> 09:36.840
in cui sono presenti degli zeri

09:36.840 --> 09:39.420
e in cui non sono rappresentate altre cifre esadecimali,

09:39.420 --> 09:42.150
posso riassumere il tutto usando i doppi due punti e togliendo

09:42.150 --> 09:44.160
tutti gli zeri.

09:44.160 --> 09:45.420
Ora, questa regola è speciale

09:45.420 --> 09:48.540
perché si possono fare i doppi due punti solo una volta all'interno

09:48.540 --> 09:50.460
di un indirizzo IPv6.

09:50.460 --> 09:52.530
Quindi, utilizzando la regola dei

09:52.530 --> 09:57.530
doppi due punti, posso riassumere 2018:0:0:0:0:0:4815:54ae rimuovendo tutte

10:00.750 --> 10:03.270
queste cinque serie di zeri e sostituendole

10:03.270 --> 10:04.950
con un doppio punto e ottenendo

10:04.950 --> 10:07.450
2018::4815::54ae.

10:10.290 --> 10:13.020
Così sono passato da 32 cifre esadecimali

10:13.020 --> 10:14.910
a 17 cifre esadecimali e ora

10:14.910 --> 10:17.160
da 17 cifre sono sceso a 12 cifre,

10:17.160 --> 10:19.080
molto più piccole, molto

10:19.080 --> 10:21.690
più facili da usare.

10:21.690 --> 10:24.240
Si può capire come questa stenografia sia davvero utile.

10:24.240 --> 10:27.150
Come si riconosce un indirizzo IPv6 rispetto

10:27.150 --> 10:28.950
a un indirizzo IPv4?

10:28.950 --> 10:32.130
Il primo modo è quello di vedere cos'è l'IPv4.

10:32.130 --> 10:35.400
IPv4 utilizzerà sempre la notazione decimale punteggiata

10:35.400 --> 10:36.990
con quattro ottetti.

10:36.990 --> 10:38.490
L'IPv6, invece, utilizzerà

10:38.490 --> 10:40.530
i due punti tra i numeri e sarà scritto

10:40.530 --> 10:42.450
in esadecimale.

10:42.450 --> 10:44.280
Bene, ora, una delle domande che potreste

10:44.280 --> 10:45.810
vedere il giorno del test è quella

10:45.810 --> 10:49.080
di identificare un indirizzo IPv6 quando ne vedete uno.

10:49.080 --> 10:51.180
Ad esempio, si potrebbe ricevere una domanda

10:51.180 --> 10:53.700
del tipo: "Quale dei seguenti è un indirizzo IPv6?

10:53.700 --> 10:55.410
Questa è una domanda giusta da porre.

10:55.410 --> 10:59.280
Avrete a disposizione alcune opzioni come 192. 168. 1. 1, che sappiamo non

10:59.280 --> 11:01.830
essere tale perché è un indirizzo IPv4.

11:01.830 --> 11:06.830
Si otterrà 12:34:56:78:90:AB

11:07.590 --> 11:12.000
o 1234::5678::90AB.

11:12.000 --> 11:15.120
Aspettate un attimo, le ultime due cose che ho appena detto

11:15.120 --> 11:17.010
sono molto simili, non è vero?

11:17.010 --> 11:20.310
Sì, ma solo uno di questi è un indirizzo IPv6 valido.

11:20.310 --> 11:21.630
Sai qual è?

11:21.630 --> 11:24.000
Perché la maggior parte degli studenti si confonde qui.

11:24.000 --> 11:28.020
La seconda opzione non è un indirizzo IPv6.

11:28.020 --> 11:29.820
Si tratta invece di un indirizzo MAC.

11:29.820 --> 11:31.260
Ricordate che gli indirizzi

11:31.260 --> 11:33.060
MAC, che sono indirizzi fisici di livello

11:33.060 --> 11:35.580
2, sono sempre composti da 12 cifre esadecimali e

11:35.580 --> 11:37.230
separati da due punti.

11:37.230 --> 11:38.370
Di solito vengono scritti

11:38.370 --> 11:40.410
come sei gruppi di due cifre ciascuno e

11:40.410 --> 11:43.200
ognuno di essi è separato da un singolo punto.

11:43.200 --> 11:46.080
Un indirizzo IPv6, invece, deve sempre essere scritto

11:46.080 --> 11:48.120
in segmenti di quattro cifre ciascuno

11:48.120 --> 11:50.580
e deve sempre avere 16 segmenti, a meno che non

11:50.580 --> 11:52.500
si veda un doppio punto.

11:52.500 --> 11:55.080
In questo esempio, abbiamo un doppio punto tra

11:55.080 --> 11:58.020
il primo e il secondo segmento della terza opzione.

11:58.020 --> 12:00.840
Si tratta quindi di una buona abbreviazione che possiamo usare

12:00.840 --> 12:03.450
per identificare che si tratta di un indirizzo IPv6 perché

12:03.450 --> 12:05.130
abbiamo rimosso tutti gli zeri tra il

12:05.130 --> 12:08.520
primo e il secondo segmento all'interno di questo indirizzo.

12:08.520 --> 12:09.960
Quindi, se si conta qualcosa

12:09.960 --> 12:11.790
che assomiglia a un indirizzo IPv6

12:11.790 --> 12:15.480
e ha 12, esattamente 12 cifre esadecimali separate da singoli punti,

12:15.480 --> 12:17.040
e non si vedono doppi punti da

12:17.040 --> 12:18.840
nessuna parte, si tratta di un indirizzo

12:18.840 --> 12:22.140
MAC, non di un indirizzo IPv6.

12:22.140 --> 12:24.180
Altrimenti, se ha un aspetto simile

12:24.180 --> 12:25.860
a questo e comprende cifre esadecimali,

12:25.860 --> 12:29.190
il giorno dell'esame sarà un indirizzo IPv6.

12:29.190 --> 12:31.440
Per l'esame, è sufficiente essere in

12:31.440 --> 12:33.540
grado di riconoscere l'aspetto di

12:33.540 --> 12:35.790
un indirizzo IPv6 e di riassumerne uno

12:35.790 --> 12:38.070
togliendo gli zeri e consolidandoli

12:38.070 --> 12:39.960
con il trucco dei due punti.

12:39.960 --> 12:41.490
Se riuscite a fare queste due cose,

12:41.490 --> 12:45.000
sarete a posto per l'indirizzamento IPv6 il giorno dell'esame.

12:45.000 --> 12:47.280
Per quanto riguarda l'indirizzamento

12:47.280 --> 12:50.100
IPv6, è possibile utilizzare tre diversi tipi

12:50.100 --> 12:52.220
di indirizzo: indirizzi unicast,

12:52.220 --> 12:54.210
multicast e anycast.

12:54.210 --> 12:56.640
Uno degli aspetti interessanti dell'IPv6,

12:56.640 --> 12:59.040
che lo distingue dall'IPv4, è la possibilità

12:59.040 --> 13:01.830
di assegnare più indirizzi IPv6 a una singola interfaccia

13:01.830 --> 13:03.900
di un client.

13:03.900 --> 13:05.730
Queste assegnazioni possono

13:05.730 --> 13:07.680
essere un misto di tre tipi diversi:

13:07.680 --> 13:10.290
unicast, multicast e anycast.

13:10.290 --> 13:13.140
Quindi, anche se si dispone di una sola scheda di interfaccia

13:13.140 --> 13:14.910
di rete sulla propria workstation

13:14.910 --> 13:17.430
o laptop, si possono avere più indirizzi IPv6

13:17.430 --> 13:19.860
e diversi tipi di indirizzi IPv6 assegnati

13:19.860 --> 13:22.140
a quell'unica scheda.

13:22.140 --> 13:23.850
Gli indirizzi unicast verranno utilizzati

13:23.850 --> 13:25.950
per identificare una singola interfaccia.

13:25.950 --> 13:28.950
Questi sono suddivisi in indirizzi unicast instradati a livello

13:28.950 --> 13:30.930
globale e indirizzi link-local.

13:30.930 --> 13:32.760
Un indirizzo unicast instradato a livello

13:32.760 --> 13:36.150
globale è simile a quello che abbiamo come indirizzo pubblico con

13:36.150 --> 13:39.600
l'IPv4, che utilizza indirizzi unicast di classe A, B e C.

13:39.600 --> 13:42.840
Ora, in IPv6, un indirizzo unicast instradato

13:42.840 --> 13:44.220
a livello globale inizierà

13:44.220 --> 13:49.050
sempre con il suo primo segmento contenente 2000-3999.

13:49.050 --> 13:52.740
Se si vede 2000-3999 come primo segmento, significa che si tratta di

13:52.740 --> 13:55.770
un indirizzo unicast instradato a livello globale.

13:55.770 --> 13:58.050
Ad esempio, l'indirizzo IPv6

13:58.050 --> 14:03.050
2584:0db8:8583:1234:5678:882e:0370:7334 verrebbe instradato

14:10.800 --> 14:14.010
globalmente come indirizzo unicast perché

14:14.010 --> 14:17.070
il suo primo segmento contiene 2584, che

14:17.070 --> 14:20.670
è compreso tra 2000 e 3999.

14:20.670 --> 14:22.650
Un indirizzo link-local, invece, chiamato

14:22.650 --> 14:24.690
anche indirizzo di uso locale, viene utilizzato

14:24.690 --> 14:28.020
come un indirizzo IP privato nell'IPv4.

14:28.020 --> 14:29.970
Un indirizzo link-local in

14:29.970 --> 14:32.097
IPv6 può essere utilizzato solo

14:32.097 --> 14:36.840
su una rete locale e inizierà sempre con FE80 come primo segmento

14:36.840 --> 14:38.940
di un indirizzo IPv6.

14:38.940 --> 14:41.760
Ora, ogni volta che un sistema IPv6 si avvia, viene creato

14:41.760 --> 14:44.100
un indirizzo link-local per ogni interfaccia

14:44.100 --> 14:47.070
IPv6 del sistema, anche se un indirizzo instradabile a livello

14:47.070 --> 14:48.720
globale è già stato configurato

14:48.720 --> 14:50.190
manualmente o ottenuto tramite

14:50.190 --> 14:53.700
un protocollo di configurazione come il DHCP.

14:53.700 --> 14:56.340
Per farlo, utilizzerà un metodo noto come SLAAC,

14:56.340 --> 15:00.840
l'autoconfigurazione stateless degli indirizzi o S-L-A-A-C.

15:00.840 --> 15:02.610
Con l'autoconfigurazione stateless,

15:02.610 --> 15:04.680
l'host non deve ottenere indirizzi o altre

15:04.680 --> 15:06.210
informazioni di configurazione

15:06.210 --> 15:08.880
da un server centralizzato come il DHCP.

15:08.880 --> 15:11.640
Invece, può assegnarsi autonomamente un indirizzo

15:11.640 --> 15:13.050
link-local, verificare l'unicità

15:13.050 --> 15:15.420
di tale indirizzo, assegnare l'indirizzo link-local

15:15.420 --> 15:17.430
a se stesso, contattare il router e fornire

15:17.430 --> 15:22.680
indicazioni al nodo su come procedere con l'autoconfigurazione.

15:22.680 --> 15:25.770
E può anche configurare l'indirizzo unicast globale

15:25.770 --> 15:27.090
da utilizzare.

15:27.090 --> 15:29.520
Torneremo su questo concetto tra qualche minuto, quando

15:29.520 --> 15:31.110
ci addentreremo un po' di più nell'argomento,

15:31.110 --> 15:34.080
iniziando a parlare di EUI-64 e del protocollo di scoperta dei vicini,

15:34.080 --> 15:35.580
poiché entrambi questi processi

15:35.580 --> 15:37.650
sono utilizzati con il protocollo di autoconfigurazione

15:37.650 --> 15:41.580
stateless degli indirizzi noto come SLAAC.

15:41.580 --> 15:43.680
Poi ci sono gli indirizzi multicast.

15:43.680 --> 15:45.360
Ora, gli indirizzi multicast vengono utilizzati

15:45.360 --> 15:47.100
per identificare un gruppo di interfacce,

15:47.100 --> 15:49.710
in modo che un pacchetto possa essere inviato a un indirizzo multicast

15:49.710 --> 15:52.680
e quindi consegnato a tutte le interfacce del gruppo.

15:52.680 --> 15:56.550
In IPv6, un indirizzo multicast conterrà sempre FF come

15:56.550 --> 15:59.460
prime due cifre del primo segmento.

15:59.460 --> 16:02.280
Se vedete FF all'inizio di un indirizzo

16:02.280 --> 16:04.800
IPv6, ricordate che è multicast.

16:04.800 --> 16:06.330
L'ultimo tipo di indirizzo che

16:06.330 --> 16:08.700
abbiamo è noto come indirizzo anycast.

16:08.700 --> 16:11.610
Gli indirizzi anycast sono utilizzati per identificare un insieme di interfacce in

16:11.610 --> 16:14.400
modo che un pacchetto possa essere inviato a qualsiasi membro dell'insieme.

16:14.400 --> 16:16.320
Gli indirizzi anycast sono in realtà allocati

16:16.320 --> 16:18.060
dallo spazio degli indirizzi unicast.

16:18.060 --> 16:19.620
Quindi non c'è modo di determinare

16:19.620 --> 16:22.710
se un indirizzo IPv6 è unicast o anycast solo guardando

16:22.710 --> 16:25.410
l'indirizzo IPv6.

16:25.410 --> 16:28.050
Ora, quando si tratta di multicast o di link-local,

16:28.050 --> 16:29.790
si ha un modo molto semplice per farlo,

16:29.790 --> 16:31.440
ma non si ha un modo semplice per capire

16:31.440 --> 16:33.870
se si tratta di unicast o anycast.

16:33.870 --> 16:35.010
Bene, torniamo a parlare

16:35.010 --> 16:36.990
un po' di più di SLAAC, il processo di

16:36.990 --> 16:40.140
autoconfigurazione degli indirizzi stateless.

16:40.140 --> 16:42.090
Come ho già detto, in IPv6 esiste un processo

16:42.090 --> 16:45.120
di autoconfigurazione noto come SLAAC, che viene utilizzato

16:45.120 --> 16:46.980
per scoprire la rete corrente in cui

16:46.980 --> 16:48.570
si trova l'interfaccia e quindi

16:48.570 --> 16:51.360
consentirle di selezionare il proprio ID host in base

16:51.360 --> 16:56.360
all'indirizzo MAC utilizzando un processo noto come EUI-64.

16:56.550 --> 17:01.410
Ora, questo processo di EUI-64 o Extended Unique Identifier consentirà

17:01.410 --> 17:03.450
a un host di assegnarsi un identificatore

17:03.450 --> 17:07.967
unico di interfaccia IPv6 a 64 bit, chiamato EUI-64.

17:09.180 --> 17:12.000
Ora, questo indirizzo in formato EUI-64 si ottiene

17:12.000 --> 17:15.480
utilizzando l'indirizzo MAC a 48 bit dell'interfaccia.

17:15.480 --> 17:19.260
L'indirizzo MAC viene prima separato in due porzioni da 24 bit.

17:19.260 --> 17:22.890
La prima metà dell'indirizzo MAC contiene l'OUI (Organizational

17:22.890 --> 17:25.170
Unique Identifier).

17:25.170 --> 17:26.850
La seconda metà conterrà la scheda

17:26.850 --> 17:29.010
di interfaccia di rete specifica.

17:29.010 --> 17:30.780
Ora, tra questi, inseriremo

17:30.780 --> 17:35.730
un valore esadecimale a 16 bit, FFFE.

17:35.730 --> 17:39.990
In questo modo, posso prendere 24 bit, 16 bit e 24 bit

17:39.990 --> 17:44.760
e metterli insieme per ottenere un indirizzo EUI a 64 bit.

17:44.760 --> 17:47.340
In questo modo si ottengono i 64 bit necessari per

17:47.340 --> 17:49.860
identificare l'interfaccia sulla rete.

17:49.860 --> 17:52.320
Quindi l'interfaccia utilizzerà l'autodiscovery

17:52.320 --> 17:53.910
per determinare la rete in cui

17:53.910 --> 17:57.030
si trova e aggiungere la porzione di rete dell'indirizzo IPv6,

17:57.030 --> 18:00.960
che sarà costituita dai primi 64 bit dei nostri indirizzi.

18:00.960 --> 18:02.940
Ora, metteremo i primi 64 bit che

18:02.940 --> 18:05.580
rappresentano la rete davanti ai 64 bit dell'indirizzo

18:05.580 --> 18:09.390
EUI-64 creato dal nostro indirizzo MAC per creare un indirizzo

18:09.390 --> 18:14.550
IPv6 unicast instradabile a livello globale che possiamo usare.

18:14.550 --> 18:16.890
Si può quindi vedere come tutto questo funzioni insieme utilizzando

18:16.890 --> 18:18.180
l'indirizzo MAC per creare questo

18:18.180 --> 18:20.700
indirizzo instradabile a livello globale.

18:20.700 --> 18:24.180
Ora, il DHCP può essere utilizzato anche nell'ambito dell'IPv6, se si

18:24.180 --> 18:25.560
preferisce utilizzarlo.

18:25.560 --> 18:29.520
In questo caso, dovrete utilizzare il protocollo DHCPv6.

18:29.520 --> 18:30.930
In questo modo si può fare in

18:30.930 --> 18:34.650
modo che il DHCP assegni automaticamente le cose da un server DHCPv6.

18:34.650 --> 18:38.520
Ma poiché il processo di autoconfigurazione con EUI-64 è già incorporato nel

18:38.520 --> 18:41.430
protocollo IPv6 per impostazione predefinita, non è necessario

18:41.430 --> 18:43.230
utilizzare il DHCPv6.

18:44.280 --> 18:47.580
Tuttavia, se si desidera utilizzare il DHCPv6, è possibile farlo e questo

18:47.580 --> 18:48.870
consente di assegnare gli indirizzi

18:48.870 --> 18:51.360
che ogni interfaccia riceverà, invece di consentire

18:51.360 --> 18:52.500
l'utilizzo del protocollo

18:52.500 --> 18:55.170
di autoconfigurazione SLAAC.

18:55.170 --> 18:58.560
Come ho detto, l'IPv6 sceglierà il proprio indirizzo in base

18:58.560 --> 19:00.930
all'indirizzo MAC per impostazione predefinita,

19:00.930 --> 19:03.480
quindi utilizzerà il protocollo NDP (neighbor

19:03.480 --> 19:05.310
discovery protocol) per conoscere

19:05.310 --> 19:09.990
gli altri indirizzi Layer 2 della rete in base ai loro indirizzi MAC e quindi sceglierà

19:09.990 --> 19:12.630
il proprio ID host.

19:12.630 --> 19:15.630
Per l'esame non è necessario conoscere a fondo l'NDP, ma è necessario

19:15.630 --> 19:17.850
capire che l'NDP, questo protocollo di scoperta

19:17.850 --> 19:20.847
dei vicini, è utilizzato in IPv6 e prende molte delle funzioni

19:20.847 --> 19:22.410
della pubblicità dei router e della

19:22.410 --> 19:25.683
scoperta dei vicini e le gestisce per voi.
