Aggiornamenti e Correzioni

Tecnologie e Servizi di Rete/chapters/02_ipv6.md

@@ -659,7 +659,7 @@ La transizione da IPv4 e IPv6, come già detto, è tutt'ora in corso e molto len
 
 ![Esempio di Tunneling](../images/02_tunneling_ipv4.png){width=400px}
 
-L'approccio inziale è stato quello di tipo dual stack descritto precedentemente, con lo scopo di supportare le funzionalità di entrambi i protocolli, ma con la limitazione di non ridurre l'utilizzo di IPv4 e di dare la responsabilità alle applicazioni di utilizzare IPv6 o IPv4.
+L'approccio iniziale è stato quello di tipo dual stack descritto precedentemente, con lo scopo di supportare le funzionalità di entrambi i protocolli, ma con la limitazione di non ridurre l'utilizzo di IPv4 e di dare la responsabilità alle applicazioni di utilizzare IPv6 o IPv4.
 
 Alcuni protocolli che implementano soluzioni di tipo tunneling sono:
 
@@ -747,15 +747,19 @@ In questa modalità le comunicazioni avvengono attraverso un tunnel broker serve
 
 Vengono utilizzati tunnel IPv6 in IPv4 (a.k.a. proto-41).
 
-Per eseguire la configurzione dei tunnel viene utilizzato il Tunnel Setup Protocol (TSP) o il Tunnel Information Control (TIC).
+Per eseguire la configurazione dei tunnel viene utilizzato il Tunnel Setup Protocol (TSP) o il Tunnel Information Control (TIC).
 
-Questo tipo di soluzione è centralizzata.
+Questo tipo di soluzione è centralizzata, questa è la sua debolezza perché deve essere gestita da qualcuno/gestore (motivo economico)
 
 ![Architettura tunnel broker](../images/02_architettura_tunnel_broker.png){width=400px}
 
 ## Scalable, Carrier-grade Solutions
 
-Devono essere presi in considerazione anche soluzioni per grandi provider. Purtroppo ancora è necessario supporto per i server e i client IPv4 in modo che possano comunicare con host IPv6 e host ipv4. Le soluzioni più utilizzate sono:
+Devono essere prese in considerazione anche soluzioni per grandi provider.
+Tante grandi reti ipv4/ipv6 che devono attraversare porzioni di reti ipv6/ipv4 connesse a tantissimi host e altrettante reti.
+Client IP che vogliono comunicare verso server di vario tipo sia IPv4 che Ipv6 (non il contrario)
+Purtroppo ancora è necessario supporto per i server e i client IPv4 in modo che possano comunicare con host IPv6 e host ipv4. 
+Le soluzioni più utilizzate sono:
 
 - **DS-Lite**
 - **A+P (evoluzione di DS-Lite)**
@@ -764,8 +768,11 @@ Devono essere presi in considerazione anche soluzioni per grandi provider. Purtr
 - **6PE (MPLS-based)**
 
 Tutte queste soluzioni si basano sul concetto di mapping di indirizzo IP, ovvero il NAT, eseguendo un mapping tra ipv4 e ipv4. Quello che viene fatto è associare una porta a un indirizzo privato.
-
-Prende il nome di _**LSN** il **L**arge **S**cale **N**AT_, utile in quanto riesce a gestire una quantità di richieste molto elevate.
+Ci sono 3 scenari possibili:
+CPE è il Customer Premises Equipment, sono i router che sono a casa del cliente che inizialmente (quando è stato coniato il termine) erano sotto il controllo del provider (home station della vodaphone) e che connettono la rete privata alla rete ipv4 del provider tramite NAT. Questo nat deve gestire pochi indirizzi ed è molto economico
+Un altro caso sono i provider che forniscono rete mobile quindi c'è un unica grande rete con indirizzamento privato a cui sono connessi direttamente milioni di utenti che deve essere connessa alla rete internet tramite un NAT sul _LSN_.
+Prende il nome di _**LSN** il **L**arge **S**cale **N**AT_, utile in quanto riesce a gestire una quantità di richieste molto elevate (mapping da 1 ip pubblico a milioni di utenti privati con indirizzo privato)
+C'è un terzo scenario che unisce quelli precedenti: il privato con la sua rete locale ha un CPE con NAT (caso 1) che si connette alla rete privata del provider (caso 2) che per andare poi su internet deve avere un NAT su _LSN_ (questo metodo è stato usato da fastweb). Abbiamo quindi l'indirizzo privato di casa che viene convertito nell'indirizzo privato del provider per poi con un NAT costoso essere convertita in indirizzo pubblico per accedere a internet.
 
 :::note
 E' possibile avere più livelli di NAT ponendoli in cascata, pratica piuttosto comune.
@@ -777,8 +784,13 @@ E' necessario tenere a mente che nelle soluzioni proposte, anche se è previsto
 
 ![Stessa architettura con IPv6](../images/02_sawi.png){width=400px}
 
+RFC1918 indica una rete privata casalinga di tipo IPV4
+Adesso i provider stanno incominciando ad usare delle reti IPv6 per connettere gli utenti alla rete internet che ancora per la maggior parte è ipv4
+
 :::warning
-**Attenzione**: da notare dove le funzionalità di NAT sono presenti.
+**Attenzione**: la posizione del NAT indica la differenza tra le varie soluzioni per mettere in comunicazione gli utenti finali dual stack a internet ipv4. L'ultima soluzione fa usare al cliente una rete Ipv6 e questo elimina un passaggio (serve comunque un NAT64). 
+Si sotto intende che avrò sempre un client che inizia la comunicazione con il server e non viceversa.
+La linea blu significa un tunnel
 :::
 
 ### AFTR: Address Family Transition Router
@@ -802,14 +814,29 @@ Permette di ridurre il numero di indirizzi IPV4 richiesti rispetto a un approcci
 
 Il NAT esteso consente l'indirizzamento assegnato dal cliente (ovvero sovrapposto).
 
+Il CPE dell'utente viene configurato con l'indirizzo IP del AFTR che si occupa di fare NAT assieme ad altri parametri come DNS attraverso DHCP o Router Advertisement.
+
+Il client IPv4 manderà il pacchetto al proprio CE che poi lo imbusterà e mandera al AFTR (tunnel end point) utilizzando come sorgente il suo indirizzo ipv6 per essere imbustato con ipv4 pubblico per mandare nella rete ipv4 pubblica.
+
+AFTR viene chiamato DS-LITE CGN
+
+Quando il server risponde il NAT sul DS-LITE CGN si occuperà di fare il mapping ipv4 e porta e il server AFTR si occuperà di instradare il pacchetto verso l'interfaccia IPv6 del CPE dell'utente.
+
+:::note
+C'è però un problema, le reti ip private devono avere indirizzi unici, per risolvere questo problema si può usare A+P oppure estendere il NAT del DS-LITE CGN per mappare anche sull'indirizzo IPv6 del CPE andando però a mischiare il software del tunnel e quello che fa NAT.
+:::
+
+I client IPv6 nella rete del cliente possono parlare direttamente con i server nella rete IPv6 esternamente al provider senza passare per AFTR.
+
 Le limitazioni sono però le seguenti:
 
 - il customer non ha controllo sul NAT.
 - problemi con il server, ad esempio static mapping e port forwarding non possono essere configurati.
+- usare indirizzi privati unici.
 
 ### A+P (Address plus Port)
 
-Il vantaggio di **A+P** è che il NAT è sotto il controllo dei customer. Una ulteriore caratteristica è che il range di TCP/UDP è assegnato a ciascun customer (solo le porte sono utilizzate dal nat in uscita).
+Il vantaggio di **A+P** è che il NAT è sotto il controllo dei customer. Una ulteriore caratteristica è che il range di porte TCP/UDP è assegnato a ciascun CPE (solo le porte sono utilizzate dal nat in uscita) cosi da non avere conflitti di ip privati uguali.
 
 Le features sono:
 
@@ -818,36 +845,41 @@ Le features sono:
 - AFTR è solo un tunnel terminator IPv4 in IPv6 (NAT44 non è più necessario in AFTR).
 
 :::tip
-**Nota**: Il concetto alla base è di spostare la complessità sulle foglie.
+**Nota**: Il concetto alla base è di spostare la complessità sulle foglie (sul CPE)
 :::
 
 ![A+P](../images/02_ap_schema.png){width=400px}
 
 ### Mapping Address and Port (MAP)
 
-Il **Mapping Address and Port** (MAP) utilizza un approccio di tipo **stateless**. Questo sfrutta i vantaggi del DHCP e del DNS anche all'interno del sistema, non associando dei range di porte ma bensì dei set: un set si differenzia dal fatto che ci sono più porte che non sono necessariamente contigue. Inoltre, il CPE utilizza la stessa rete pubblica IPv4, così non da non avere limitazioni.
+Voglio eliminare lo stato nel AFTR semplificandolo non usando le tabelle. Le informazioni di mapping le scrivo nell'indirizzo IPV6 essendoci 128bit per ricostruire il percorso inverso.
+AFTR si chiama Border Relay. Scalabile e tutto basato su prefissi.
+Il **Mapping Address and Port** (MAP) utilizza un approccio di tipo **stateless** (mapping non piu' fatti via tabella). Questo sfrutta i vantaggi del DHCP e del DNS anche all'interno del sistema, non associando dei range di porte ma bensì dei set: un set si differenzia dal fatto che ci sono più porte che non sono necessariamente contigue. Inoltre, il CPE utilizza la stessa rete pubblica IPv4, così non da non avere limitazioni.
 
+Si usano molto dai provider.
 L'indirizzo e la porta del client IPv4 sono mappati in un unico indirizzo IPv6 (prefix routed dal CPE).
 
 L'indirizzo del server pubblico IPv4 è anche questo mappato in un unico indirizzo IPv6 (prefix routed dal Border Relay).
 
 Esistono due tipi di MAP:
 
-- **MAP-E**: MAP with Encapsulation, ovvero i pacchetti IPv4 vengono tunnelizzati.
+- **MAP-E**: MAP with Encapsulation, ovvero i pacchetti IPv4 vengono tunnelizzati per entrare nella rete IPv6.
 - **MAP-T**: MAP with Translation, i pacchetti IPv4 sono tradotti in pacchetti IPv6 e poi nuovamente in IPv4.
 
-Quando però avviene la sostituzione di un header IPv6 con un header IPv4 è necessario fare attenzione a non perdere informazioni.
+Quando però avviene la sostituzione di un header IPv6 con un header IPv4 è necessario fare attenzione a non perdere informazioni (viene fatto per non usare le tabelle)
 
 ### Port Set
 
-A ogni CPE viene assegnato un unico **PSID** (Port set Identifier) che identifica un set di porte e un indirizzo pubblico IPv4.
+A ogni CPE viene assegnato un unico **PSID** (Port set Identifier)(serve per distinguere i CPE con stesso indirizzo IPv4) che identifica un set di porte (possono non essere contigue, per semplificare la vita ai load balancer) e un indirizzo pubblico IPv4 (il nat si prevede di farlo sul cpe come su A+P).
 
 Per creare un set di porte si utilizzano 16 bit, composte da:
 
-- A: identifica il dominio (ad esempio si assegna a un _CPE_ le porte con i bit che iniziano con 1100).
-- PSID: identifica il set di porte (lunghezza variabile).
+- A: identifica il dominio (ad esempio si assegna a un _CPE_ le porte con i bit che iniziano con 1100)(psid offset)(il prefisso è variabile per generare un SET, se a fosse un prefisso avrei un insieme di porte continue).
+- PSID: identifica il set di porte (lunghezza variabile). 
 - j: insieme delle porte.
 
+Inoltre, un offset PSID (valore di a) viene settato per l'intero dominio di mappatura.
+
 ![Port set](../images/02_portset.png){width=350px}
 
 :::danger
@@ -858,28 +890,41 @@ L'embedded Address (EA) contiene i bit di PSID e parzialmente l'indirizzo IPv4 (
 
 ### Mapping Rules
 
-Le regole per il mapping sono:
+Tramite le informazioni seguenti il CPE si calcola l’indirizzo IPv6 da utilizzare nell’interfaccia esterna come sorgente del tunnel(dette anche regole di mapping):
 
-- IPv6 prefix rule
+- IPv6 prefix rule (comuni dello steso provider)
 - IPv4 prefix rule: prefisso IPv4 di un indirizzo IPv4 utilizzato da un determinato CPE.
-- EA bits length
+- EA bits length (combinazione tra indirizzo IPv4 del NAT e PSID)(per ricostruire la strada a ritroso)
+- Subnet ID di solito zeri (spesso non usato)
+- Interface Identifier che contiene gli indirizzi IPv4 del CPE NAT e PortSet
 
-Inoltre, un offset PSID (valore di a) viene settato per l'intero dominio di mappatura.
-
-Tramite queste informazioni il CPE si calcola l’indirizzo IPv6 da utilizzare nell’interfaccia esterna.
+Qual'è l'indirizzo di destinazione del tunnel (Border Relay)?
 
 ### Border Relay
 
 L'indirizzo del border relay deve essere conosciuto da tutti i CPE, anche se più BR possono avere lo stesso indirizzo (anycasting).
+A cui devo trasmettere l'indirizzo iPV4 del mittente e la porta sorgente che fa parte del mio set.
+Non è completamente stateless,devo scrivere i parametri che abbiamo visto prima per mandarlo a quella che prima era la sorgente del pacchetto dopo il NAT. Devo convertire Ipv4 in Ipv6 con le stesse regole di prima che erano sul CPE (dal prefisso /n conosco EA e PSID offset). 
+Quindi ho solo regole sui prefissi.
+
+:::danger
+Dal PSID offset vado a prendere dal numero di porta il PSID di destinazione. 
+:::
+
+Mentre nel MAP-E il BR termina il tunnel (rimanda il pacchetto cosi com'è verso il server), nel MAP-T il BR è responsabile della traduzione degli indirizzi IPv4 verso l'esterno (sostituisco l'header IPv4 con un header IPv6). Il BR prefix viene advertised sul backbone (e potrebbe essere advertised da più BR).
+Nel MAP-T le cose si complicano, diventa piu' complicato sul border relay rimettere l'header ipv4 giusto che è stato tolto dal CPE (ha perso qualche informazione ad esempio il server ipv4 di destinazione). La soluzione è usare un IPV4-embedded IPV6 per scrivere dentro IPv6 l'indirizzo Ipv4 di destinazione (RFC 6052). I CPE vengono a conoscenza di questo IPv6 tramite protocolli di routing e lo usano come sorgente (?).
+Il boarder relay deve cosi' memorizzare pochissimi parametri.
 
-Mentre nel MAP-E il BR termina il tunnel, nel MAP-T il BR è responsabile della traduzione degli indirizzi IPv4 verso l'esterno (sostituisco l'header IPv4 con un header IPv6). Il BR prefix viene advertised sul backbone (e potrebbe essere advertised da più BR).
 
 ![Vita di un pacchetto con MAP-E](../images/02_mape.png){width=400px}
 
 ![Vita di un pacchetto con MAP-T](../images/02_mapt_life.png){width=400px}
 
 ## NAT64 + DNS64
 
+Usato quando abbiamo Ipv 6 fino a quando non dobbiamo entrare nella rete vecchia. Devo gestire un unico passaggio.
+Utilizza IpV4 embedded per la destinazione e per saperlo uso un DNS64 piu' evoluto che utilizza query di tipo AAAA che il server autoritativo non avrà, segue una richiesta di tipo A, il dns la riceve e nella risposta mette l'ipv4 nell'ipv6 con il meccanismo embedded. Questo ip andrà al NAT64 che lo userà per trasformarlo in ipv4.
+
 Il NAT64 è un meccanismo di transizione a IPv6 che facilità la comunicazione tra IPv4 ed IPv6 utilizzando il _Network Address Translation_ (NAT), che traduce indirizzi e pacchetti _IPv6_ in _IPv4_, prendendo un indirizzo/porta _Ipv4_ liberi dal pool e realizzando un NAT session entry.
 
 Questa  tecnica  risolve  il  problema  della  **rete  IPv6  con  host  IPv6**  che  deve  comunicare  con  la  rete  pubblica IPv4. In questo caso, la soluzione è il NAT64 che rimuove l’header IPv6 per inserire l’header IPv4 ma per farlo viene utilizzato il DNS64.