IT knowledge base
CTRL+F per cercare la tua parola chiave

Un mondo in cui IPv6 è ben congegnato

Traduzione di un articolo di Avery Pennarun, uno dei dipendenti di Google, sul perché Internet moderno è così com'è, sulla storia e sui prerequisiti della creazione di IPv6, nonché su come sarebbe organizzato il protocollo IPv6 ideale, perché non è così, e come avvicinarsi a questo ideale.
Lo scorso novembre, sono andato per la prima volta a un incontro IETF. L'IETF è un posto interessante: sembra che un terzo del duro lavoro, un terzo dell'espansione di cose già create e un terzo della ricerca pazza e lontana dalla realtà (in questo luogo Avery ha usato la frase "pazzia del cielo blu" , formato da lui dall'espressione ricerca cieli blu - trad. ca.) . Sono stato coinvolto principalmente perché volevo vedere come le persone avrebbero reagito a TCP BBR, che è stato introdotto per la prima volta . (Risposta: per lo più positiva, ma con un pizzico di sale. Sembrava troppo bravo per essere all'altezza delle aspettative.)
Comunque sia, gli incontri IETF includono molte presentazioni su IPv6, che avrebbe dovuto sostituire il protocollo IPv4 che costituisce la base di Internet. (Alcuni direbbero che la sostituzione è già in corso, altri direbbero che è già avvenuta.) Oltre a queste presentazioni su IPv6, ci sono un gran numero di persone che lo considerano il migliore, il più grande di tutti, e sono fiduciosi che finalmente arriverà (in qualsiasi momento) e IPv4 è solo un grande mucchio di hack destinati a morire per rendere Internet di nuovo bello.
Ho pensato che sarebbe stata una buona opportunità per cercare di capire davvero cosa stava succedendo. Perché IPv6 è così confuso rispetto a IPv4? Non sarebbe meglio se fosse solo IPv4 con più bit nell'indirizzo ? Ma no, per carità, non si fa così. Così ho iniziato a chiedere a tutti in giro, ed è quello che ho imparato.

Le gomme hanno distrutto tutto

C'era una volta una rete telefonica che utilizzava la commutazione di circuito fisico. Ciò significava essenzialmente spostare i connettori in modo che il telefono fosse letteralmente collegato con un cavo molto lungo ( OSI layer 1 ). E la "linea dedicata" era il filo più lungo che hai preso in affitto dalla compagnia telefonica. Metti i pezzi su un lato di questo filo e loro escono dall'altra estremità dopo un determinato periodo di tempo. Non avevi bisogno di indirizzi perché c'era solo una macchina a ciascuna estremità.
Le compagnie telefoniche una volta hanno modificato un po' tutto. Sono stati introdotti il ​​multiplexing a divisione di tempo (TDM) e la "commutazione di canale virtuale". Le compagnie telefoniche potrebbero prendere in modo trasparente bit a bassa velocità da molte linee, raggrupparli utilizzando multiplexer e demultiplexer e farli passare attraverso il sistema telefonico utilizzando meno cavi rispetto a prima. C'è voluto più lavoro per farlo funzionare rispetto a prima, ma per ora, per noi utenti di modem, tutto era lo stesso: mettevamo i bit da una parte, loro strisciavano fuori dall'altra. Nessun indirizzo necessario.
Internet (non ancora chiamato così) è stato costruito su questi canali. Avevi un mucchio di fili in cui potevi infilare dei pezzi e prendere dall'altra parte. Se un computer ha due o tre interfacce di rete, può, se adeguatamente istruito, inviare bit da una linea all'altra e puoi fare qualcosa di molto più efficiente che avere linee di comunicazione separate tra ogni coppia di computer. E così sono comparsi gli indirizzi IP ("livello 3"), le sottoreti e il routing. Anche allora, con questi collegamenti punto-punto, non avevi bisogno di indirizzi MAC, perché una volta che un pacchetto era in rete, c'era solo un posto per estrarlo. Hai solo bisogno degli indirizzi IP per decidere dove dovrebbe andare dopo.
Nel frattempo, le reti locali (LAN) sono state inventate come alternativa. Se volevi connettere i tuoi computer (o terminali e il mainframe) a casa, hai avuto l'inconveniente delle molte interfacce che dovevi avere per ogni connessione in una topologia a stella. Per contenere i costi dell'elettronica, le persone avevano bisogno di una rete "bus" (nota anche come "dominio di trasmissione", un concetto che sarà importante in seguito) in cui più stazioni potessero essere semplicemente collegate a un singolo cavo e parlare con chiunque fosse connesso. esso. Queste non erano le stesse persone che hanno costruito Internet, quindi non hanno usato gli indirizzi IP per questo. Hanno inventato il loro circuito ("livello 2").
Una delle prime LAN "bus" era arcnet a me cara (ho scritto il primo driver arcnet per Linux e versi arcnet nei primi anni novanta, molto tempo dopo che arcnet era obsoleto). Gli indirizzi Arcnet Layer 2 erano molto semplici: solo 8 bit impostati da jumper o DIP switch sul retro della NIC. Stava a te come proprietario della rete impostare gli indirizzi e assicurarti di non avere duplicati, altrimenti sarebbe potuto accadere l'inferno. È stato un po' doloroso, ma le reti di Arcnet di solito erano abbastanza piccole da essere solo una parvenza di dolore.
Alcuni anni dopo è arrivata Ethernet e ha risolto questo problema una volta per tutte utilizzando molti più bit (48, in realtà) negli indirizzi di livello 2. Questo è un bit sufficiente per poterne assegnare uno diverso dagli altri (sharded-serial (qui, a quanto pare, significa che i primi tre byte dell'indirizzo MAC sono assegnati come intervallo per un produttore specifico - circa trad.) ) Indirizzo a ciascun dispositivo che quando è stato rilasciato e non ha intersezioni. Ed è esattamente quello che hanno fatto! Ecco come apparivano gli indirizzi MAC Ethernet.
Diverse tecnologie LAN sono venute e scomparse, inclusa una delle mie preferite, IPX ( internetwork, sebbene non avesse nulla a che fare con la "vera" Internet) e Netware, che funzionava benissimo, fino a quando tutti i client e i server erano sul rete dallo stesso bus. Non hai mai dovuto impostare alcun indirizzo. Era bello, affidabile ed efficiente. In pratica, l'età d'oro del networking.
Certo, qualcuno doveva distruggerlo: grandi reti di aziende/università. Volevano così tanti computer collegati che la condivisione di 10 Mbps su un singolo bus tra di loro è diventata un collo di bottiglia, quindi avevano bisogno di un modo per avere più bus e per interconnettere - "internet" se vuoi - quei bus insieme. Probabilmente stai pensando: "Certo! Usa il protocollo Internet (IP) per questo, "giusto? Haha no. Il protocollo Internet, ancora non chiamato così, non era abbastanza vecchio e popolare all'epoca, e nessuno lo prendeva sul serio. Netware-over-IPX (e numerosi altri protocolli LAN all'epoca) era un'attività seria e, come ogni attività seria, inventarono i propri espedienti per estendere la crescente popolarità di Ethernet. I dispositivi su Ethernet avevano già indirizzi, indirizzi MAC, che erano probabilmente l'unica cosa su cui le persone che utilizzavano protocolli LAN diversi potevano concordare, quindi decisero di utilizzare gli indirizzi Ethernet come chiavi per i loro meccanismi di routing. (In realtà, invece di "routing", lo chiamavano bridging e commutazione.)
Il problema con gli indirizzi Ethernet è che vengono assegnati in sequenza in fabbrica in modo che non possano essere gerarchici. Ciò significa che la "tabella di bridging" non è buona come una moderna tabella di routing IP, che può registrare un percorso verso un'intera sottorete contemporaneamente. Per realizzare un bridging efficace, dovevi ricordare su quale rete bus si trova ciascun indirizzo MAC. E gli umani non volevano sintonizzare ognuno di loro con le mani, quindi hanno dovuto capirlo da soli. Se avevi un intricato collegamento di reti, le cose si complicavano un po'. Per quanto ho capito, questo è ciò che ha portato alla poesia sull'albero di spanning , e probabilmente lo lascerò qui. La poesia è molto importante nel networking.
Tuttavia, per la maggior parte ha funzionato, anche se era un po' confuso, e si trasmettevano allagamenti qua e là, e le rotte non erano sempre ottimali, ed era quasi impossibile eseguire il debug. (Sicuramente non potresti scrivere qualcosa come traceroute per i bridge, perché nessuno degli strumenti necessari per farlo funzionare, come essere in grado di configurare un indirizzo su un bridge intermedio, non esiste su Ethernet nudo.)
D'altra parte, tutti questi bridge sono stati ottimizzati per l'hardware. Zhelezyachniks ha semplicemente inventato l'intero sistema come un meccanismo per ingannare il software, che non aveva idea dei numerosi bus e ponti tra di loro, in modo che potesse funzionare in reti più grandi. Il bridging hardware significa che il bridge può essere davvero veloce, veloce quanto la stessa Ethernet. Ora non sembra qualcosa di eccezionale, ma all'epoca era molto. Ethernet era 10 Mbps, quindi probabilmente potresti batterlo collegando più computer contemporaneamente, ma un computer non potrebbe fornire 10 Mbps. Sembrava pazzesco in quei giorni.
Ad ogni modo, il punto è che il bridging era disordinato e impossibile da eseguire il debug, ma era veloce.

Internet in autobus

Mentre tutto ciò accadeva, quegli stessi utenti di Internet si sono messi al lavoro e, naturalmente, non hanno perso la comparsa di fantastiche tecnologie LAN economiche. Penso che questo potrebbe essere stato più o meno nello stesso periodo in cui ARPANET veniva rinominato su Internet, anche se non ne sono sicuro. Diciamo che lo ha fatto, perché la storia suona meglio se raccontata con sicurezza.
Ad un certo punto, i progressi si sono spostati dalla connessione di singoli computer a Internet tramite collegamenti punto-punto a lunga distanza al desiderio di connettere intere reti locali attraverso connessioni punto-punto. In generale, volevo avere "ponti lunghi".
Potresti pensare: "Ehi, nessun problema, perché non costruire un ponte su una lunga fila e farla finita?" Suona bene, ma non funziona. Non entrerò nei dettagli, ma in poche parole il problema è il controllo del sovraccarico (purtroppo, per qualche ragione, non esiste una traduzione russa di questo articolo sul wiki - ca. Trad.) . Lo spaventoso oscuro segreto del bridging Ethernet è il presupposto che tutte le connessioni funzionino all'incirca alla stessa velocità e/o siano gravemente sottoutilizzate perché non dispongono di un meccanismo di frenatura. Devi solo sputare i dati il ​​più velocemente possibile e aspettarti che arrivi. Ma quando la tua Ethernet funziona a 10 Mbps e la tua connessione punto-punto funziona a 0,128 Mbps, è completamente senza speranza. Un altro problema è che capire i percorsi inviando attraverso tutti i canali per capire quale è corretto - e quindi il bridging di solito funziona - è troppo costoso per le connessioni lente. E il routing non ottimale, fastidioso nelle reti locali, dove bassa latenza e alto throughput, su canali di comunicazione a lunga distanza lenti e costosi, è completamente disgustoso. Semplicemente non scala.
Fortunatamente, gli utenti di Internet (se Internet si chiamava già così) hanno lavorato esattamente sugli stessi problemi. Se potessimo usare gli strumenti Internet per connettere i bus Ethernet insieme, saremmo in buona forma.
E poi hanno sviluppato un "formato frame" per i pacchetti Internet su Ethernet (e arcnet così come tutti gli altri tipi di LAN).
E qui è andato tutto storto.
Il primo problema da risolvere era che ora, quando si metteva il pacco nel filo, diventava del tutto incerto quale macchina dovesse "sentirlo" e, possibilmente, inoltrarlo ulteriormente. Se più router Internet sono sullo stesso segmento Ethernet, non è possibile far accettare a tutti il ​​pacchetto e provare a inoltrarlo; è un percorso verso le tempeste di pacchetti e le rotte in loop. No, devi scegliere da solo quale router sul bus Ethernet dovrebbe prenderlo. Non possiamo semplicemente usare il campo dell'indirizzo IP di destinazione per questo, perché abbiamo già annotato l'indirizzo del destinatario del messaggio lì, non l'indirizzo del router. Invece, identifichiamo il router desiderato utilizzando il suo indirizzo MAC nel frame Ethernet.
Quindi, per impostare la tabella di instradamento IP locale, dovresti essere in grado di dire qualcosa come "invia pacchetti a 10.1.1.1 tramite un router con MAC 11: 22: 33: 44: 55: 66". Questo è ciò che vorresti esprimere. Importante! La destinazione del tuo pacchetto è un indirizzo IP, ma il tuo router è un MAC. Ma se hai mai impostato una tabella di routing, potresti aver notato che nessuno le scrive in quel modo. Invece, scrivi: "invia pacchetti a 10.1.1.1 tramite un router a 192.168.1.1".
In realtà, complica solo le cose. Ora il tuo sistema operativo deve prima trovare l'indirizzo MAC per 192.168.1.1, capire che è 11: 22: 33: 44: 55: 66 e infine assemblare il pacchetto con l'indirizzo di destinazione Ethernet 11: 22: 33: 44: 55 : 66 e l'indirizzo IP di destinazione è 10.1.1.1. L'indirizzo 192.168.1.1 non è specificato da nessuna parte nel pacchetto, è solo un'astrazione per le persone.
Per compiere questo inutile passaggio intermedio, è necessario aggiungere ARP (Address Resolution Protocol), un semplice protocollo non IP che converte un indirizzo IP in un indirizzo Ethernet. Questo viene fatto trasmettendo una richiesta a tutti sul segmento Ethernet locale, chiedendo se hanno questo indirizzo IP. Se hai bridge, devono inoltrare tutti i pacchetti ARP su tutte le loro interfacce, perché sono pacchetti broadcast, che è ciò che significa broadcasting. Su una rete Ethernet grande e trafficata con molte LAN interconnesse, le trasmissioni eccessive sono uno dei tuoi incubi. Questo è particolarmente negativo nelle reti WiFi. Nel corso del tempo, per combattere questo problema, le persone hanno escogitato bridge / switch con hack speciali per evitare l'inoltro ARP il più a lungo tecnicamente possibile. Alcuni dispositivi (in particolare gli hotspot Wi-Fi) rispondono semplicemente con risposte ARP fasulle per aiutare. Ma queste sono tutte stampelle, anche se a volte necessarie.

Morte per eredità

Il tempo passò. Un giorno (e in realtà ci è voluto molto tempo) le persone hanno praticamente smesso di usare protocolli non IP su Ethernet. Quindi fondamentalmente tutte le reti sono diventate un cavo fisico (livello 1), con molte stazioni sul bus (livello 2), i bus sono collegati a ponte (farsi prendere! Sempre livello 2) e questi inter-bus sono collegati da router IP (livello 3 ).
Dopo un po', le persone si sono stancate di configurare manualmente indirizzi IP in stile arcnet e volevano che si configurassero da soli, in stile Ethernet, beh, tranne per il fatto che era troppo tardi per farlo in stile Ethernet perché a) i dispositivi erano già in produzione con Indirizzi Ethernet, non IP, b) gli indirizzi IP erano solo a 32 bit, il che non è sufficiente per produrli all'infinito senza intersezioni, e c) la semplice assegnazione sequenziale di indirizzi IP invece di utilizzare sottoreti ci riporterebbe all'inizio: questo sarebbe un'altra Ethernet creata da zero e abbiamo già Ethernet.
E poi sono comparsi bootp e DHCP. Questi protocolli, tra l'altro, sono speciali, come ARP (solo che cercano di non essere speciali, essendo tecnicamente pacchetti IP). Devono essere speciali perché il nodo IP deve essere in grado di inviarli prima di ottenere un indirizzo IP, il che ovviamente non è possibile, quindi popola semplicemente le intestazioni IP con essenzialmente senza senso (anche se specificato da RFC) in modo che possano essere gettato al sicuro. ... (Riconosci queste intestazioni senza senso perché DHCP deve aprire un socket non elaborato e popolarlo manualmente; il livello IP nel kernel non può farlo.) Ma nessuno era ansioso di inventare un altro protocollo che non fosse IP, quindi hanno finto di essere questo è l'IP e tutti erano felici. Bene, per quanto possibile quando inventi DHCP.
Mi sono un po' distratto. Ecco il trucco: a differenza dei servizi IP reali, bootp e DHCP devono conoscere gli indirizzi Ethernet perché, dopo tutto, è loro compito ascoltare i tuoi indirizzi Ethernet e assegnarti indirizzi IP su cui lavorare. In effetti è il trattamento del protocollo ARP, solo che non possiamo dirlo, perché esiste già un protocollo RARP, che è letteralmente "reverse ARP» (reverse ARP - ca. Perevi..). RARP in realtà ha funzionato abbastanza bene e ha fatto la stessa cosa di bootp e DHCP, essendo molto più semplice, ma non parliamo di questo.
Il punto di tutto questo è che Ethernet e IP sono diventati sempre più intrecciati. Ora sono praticamente inseparabili. È difficile immaginare un'interfaccia di rete (diversa da ppp0) senza un indirizzo MAC a 48 bit ed è difficile immaginare che questa interfaccia funzioni senza un indirizzo IP. Annoti la tua tabella di routing IP usando gli indirizzi IP, ma ovviamente sai che stai mentendo nominando un router con il suo indirizzo IP; stai solo indirettamente dicendo che vuoi instradare attraverso l'indirizzo MAC. E hai ARP, che passa attraverso i bridge, ma per divertimento, e DHCP, che è IP, ma in realtà Ethernet, e così via.
Inoltre, abbiamo ancora sia il bridging che il routing, ed entrambi diventano più complicati, mentre anche le LAN e Internet diventano sempre più complicate. Il bridging è ancora in gran parte basato sull'hardware e definito dall'IEEE, le persone che governano gli standard Ethernet. Il routing è ancora in gran parte definito dal software e definito dall'IETF, le persone che controllano gli standard Internet. Entrambi i gruppi stanno ancora cercando di fingere che non ci sia un altro gruppo. Gli operatori di rete scelgono semplicemente il bridging rispetto al routing in base alla velocità con cui vogliono che funzioni e quanto odiano la configurazione del server DHCP, che in realtà odiano molto, il che significa che utilizzano il bridging il più possibile e il routing. .
In effetti, i bridge sono andati così fuori controllo che le persone hanno deciso di portare le decisioni prese a livello di bridge completamente a un livello superiore (ovviamente, lo scambio di configurazione tra i bridge avviene utilizzando un protocollo su IP!) In modo che possano essere gestiti centralmente . Questo è chiamato Software Defined Networking (SDN). Questo è molto meglio che consentire a switch e bridge di fare ciò che vogliono, ma è anche fondamentalmente stupido perché sai cos'è l'SDN? IP. È letteralmente, ed è sempre stato, l'SDN che usi per connettere reti che sono diventate troppo grandi. Ma il problema è che inizialmente IPv4 era troppo difficile da accelerare con l'hardware e, in ogni caso, non era accelerato dall'hardware e l'impostazione di DHCP è un vero inferno, quindi gli operatori di rete hanno appena imparato a collegare entità sempre più grandi. Al giorno d'oggi, i data center di grandi dimensioni sono semplicemente basati su SDN e potresti anche non utilizzare affatto l'IP nel data center, perché nessuno sta instradando i pacchetti. È solo una grande rete di autobus.
Questo è, in breve, un disastro.

Ora dimentica che ho detto tutto questo ...

Bella storia, no? Buona. Ora facciamo finta che niente di tutto questo sia successo, e siamo tornati agli anni '90, quando la maggior parte di ciò è successo davvero, ma le persone all'IETF hanno ancora fatto finta che ciò non fosse accaduto e che la catastrofe "imminente" potesse essere evitata. Questa è la parte buona!
Ho dimenticato di menzionare qualcosa in questa lunga storia sopra: da qualche parte in questa catena di eventi, abbiamo completamente smesso di usare le reti di autobus . Ethernet non è più davvero un bus. Fa solo finta di essere una gomma. Per dirla semplicemente, non siamo riusciti a far funzionare il famoso CSMA / CD con l'aumento della velocità, quindi siamo tornati alla buona vecchia topologia a stella. Abbiamo un fascio di cavi dallo switch, quindi possiamo allungare un cavo da ogni stazione al centro. Le pareti, il soffitto e il pavimento sono pieni di grossi, spessi e costosi fasci di cavi Ethernet perché non siamo riusciti a capire come far funzionare bene il bus... al livello 1. È un po' divertente se ci pensi. A meno che, naturalmente, non trovi divertenti le cose tristi.
In effetti, in un impeto di frenesia, anche il WiFi - il caso estremo di una rete di autobus - è corretto! - dove letteralmente tutti condividono lo stesso ambiente open space, utilizziamo il WiFi quasi ovunque in una modalità chiamata infrastruttura, che emula una topologia a stella gigante. Se hai due postazioni WiFi collegate allo stesso punto di accesso, non comunicano direttamente tra loro, anche quando riescono a “sentirsi” bene. Inviano un pacchetto all'AP, ma indirizzato all'indirizzo MAC dell'altro nodo. Il punto di accesso lo riflette quindi verso il nodo di destinazione.
TIENI IL TUO CAVALLO LASCIA CHE TE LO SPIEGHI. C'è un problema qui. Quando il nodo X vuole inviare qualcosa a Internet al nodo Z, tramite il router IP Y, tramite il punto di accesso Wi-Fi A, come appare il pacchetto? Disegniamo un'immagine ciò che vogliamo:

X -> [wifi] -> A -> [wifi] -> Y -> [internet] -> Z

Z è l'indirizzo IP di destinazione, quindi ovviamente il campo di destinazione IP dovrebbe essere Z. Y è il router, che, come abbiamo appreso sopra, specifica il suo indirizzo MAC Ethernet nel campo di destinazione Ethernet. Ma in Wi-Fi, X non può semplicemente inviare un pacchetto a Y, per vari motivi (incluso il non conoscere le chiavi di crittografia WPA2 dell'altro). Dobbiamo inviare ad A. Potresti chiedere dove mettiamo l'indirizzo A?
Non è un problema! 802.11 ha una cosa come la triade. Hanno aggiunto un terzo indirizzo MAC Ethernet a ciascun frame in modo che possano parlare della vera destinazione Ethernet e della destinazione Ethernet intermedia. Inoltre, ci sono campi di bit chiamati "to-AP" ​​​​e "from-AP" che ti dicono che il pacchetto sta andando da stazione a punto di accesso o da punto di accesso a stazione, rispettivamente. Ma in realtà, possono essere entrambe vere, perché i ripetitori Wi-Fi fanno questo (l'AP invia i pacchetti all'AP).
A proposito di ripetitori! Se A è un ripetitore, deve rimandare alla stazione base B lungo un percorso simile a questo:

X -> [wifi] -> A -> [ripetitore wifi] -> B -> [wifi] -> Y -> [internet] -> Z

X-> A utilizza la modalità a tre indirizzi, ma su A-> B c'è un problema: l'Ethernet di origine è X e l'Ethernet di destinazione è Y, ma il pacchetto viene inviato via etere da A a B; X e Y non sono affatto coinvolti. Basti dire che esiste una modalità a quattro indirizzi e funziona esattamente come potresti pensare.
Le reti mesh (802.11 hanno una modalità chiamata sei indirizzi, che è il punto in cui ho rinunciato a cercare di capirlo.)

Avery, mi era stato promesso IPv6 e non l'hai ancora menzionato

Oh, oh. Questo post è un po' fuori dai binari, non credi?
Questo è lo scopo di tutta questa storia. Le persone dell'IETF, quando hanno inventato IPv6, hanno esaminato l'intero casino - e forse hanno previsto ancora più confusione che stava per apparire, anche se dubito che potessero prevedere le modalità SDN e ripetitore WiFi - e hanno detto, aspetta un minuto, aspettare. Non abbiamo bisogno di tutta questa merda! E se, invece, il mondo intorno a noi funzionasse così:
  • Niente più reti bus fisiche (fatto!)
  • Niente più internet di livello 2 (c'è un terzo livello per quello)
  • Niente più trasmissioni (il livello due sarà sempre punto-punto, quindi dove invierai la trasmissione? Sostituisci con multicast)
  • Niente più indirizzi MAC (nelle reti punto-punto è ovvio chi è il mittente e chi è il destinatario, e puoi anche fare multicast sugli indirizzi IP)
  • Niente più ARP e DHCP (nessun indirizzo MAC, quindi nessuna mappatura da IP a MAC)
  • Niente più intestazioni IP complesse (così puoi accelerare il routing hardware)
  • Mai più a corto di indirizzi IP (così possiamo tornare al routing di grandi sottoreti)
  • Niente più configurazione manuale degli indirizzi IP, ad eccezione del kernel ( e abbiamo così tanti indirizzi IP che possiamo distribuire ricorsivamente le sottoreti attraverso l'albero da lì)
Immagina di vivere in un mondo del genere: i ripetitori WiFi sarebbero solo router IPv6. E anche i punti di accesso. E switch Ethernet. E SDN. Le tempeste ARP sarebbero finite. Ogni problema di routing potrebbe essere tracerout. Soprattutto, potremmo rimuovere 12 byte (indirizzi MAC di origine e destinazione) da ciascun pacchetto Ethernet e 18 byte (origine / destinazione / hotspot) da ciascun pacchetto WiFi. Ovviamente, IPv6 aggiungerà altri 24 byte di indirizzi per noi (rispetto a IPv4), ma eliminerai 12 byte di Ethernet, quindi l'overhead è di soli 12 byte, paragonabile all'utilizzo di due indirizzi IP a 64 bit se esci l'intestazione Ethernet. L'idea che un giorno potremmo essere in grado di abbandonare gli indirizzi Ethernet ha aiutato a giustificare l'ingorgo degli indirizzi IPv6.
Sarebbe bellissimo. Tranne un problema: non è successo.

Requiem per un sogno

Un collega al lavoro ha detto meglio di tutti: "i livelli vengono sempre aggiunti e non scompaiono mai".
Tutti questi miracoli richiedono la capacità di ricominciare e buttare via l'eredità accumulata fino a quel momento. E questo, purtroppo, è per la maggior parte impossibile. Anche se IPv6 raggiungesse il 99% di penetrazione, ciò non significherebbe che ci siamo sbarazzati di IPv4. E se non ci siamo sbarazzati di IPv4, non ci siamo sbarazzati degli indirizzi Ethernet o degli indirizzi WiFi. E se dobbiamo aderire agli standard di frame IEEE 802.3 e 802.11, non possiamo mai buttare via quei byte. Pertanto, avremo sempre bisogno del rilevamento dei vicini IPv6, che è semplicemente un ARP più complesso. Anche se non utilizziamo più le reti bus, avremo sempre bisogno di un qualche tipo di trasmissione, perché è così che funziona ARP. Avremo bisogno di mantenere il nostro server DHCP locale in esecuzione a casa per mantenere in funzione le nostre lampadine IPv4 legacy. Avremo ancora bisogno di NAT per ottenere lampadine IPv4 legacy per raggiungere Internet.
E questa non è la parte peggiore. Peggio ancora, abbiamo ancora bisogno dell'abominio infinito del bridging di livello 2, a causa di un altro bug che il team IPv6 ha dimenticato di correggere . Sfortunatamente, quando stavano sviluppando IPv6 negli anni '90, l'idea era di lanciare prima IPv6 - questo avrebbe dovuto richiedere diversi anni - e poi lavorarci quando gli indirizzi IPv4 e MAC erano spariti, quindi questo compito sarebbe stato più facile da risolvere e on A quel punto, nessuno aveva comunque un vero "dispositivo IP mobile". Cioè, cosa significherebbe portare con sé un laptop e collegarlo alle porte Ethernet una per una, mentre il file viene scaricato tramite FTP? Sembra stupido.

Killer App: IP mobile

Naturalmente, con un paio di decenni di storia alle spalle, ora conosciamo diversi esempi di computer portatili - il tuo telefono - e che lo collegano alle porte Ethernet dei punti di accesso wireless, uno dopo l'altro. Lo facciamo sempre. E con LTE, funziona anche in pratica! Con il WiFi, funziona solo occasionalmente. Non male, vero?
Non proprio, a causa del vergognoso segreto di Internet: funziona solo grazie al bridging di secondo livello. Il routing di Internet non funziona affatto con la mobilità. Se navighi in una rete IP, il tuo indirizzo IP cambia e questo interrompe tutte le connessioni che apri.
Le reti WiFi aziendali ti ingannano collegando l'intera LAN al secondo livello, in modo che un gigantesco server DHCP centrale ti dia sempre lo stesso indirizzo IP, indipendentemente dal punto di accesso aziendale a cui ti connetti, e poi ti consegna i tuoi pacchetti, al massimo si interrompe per alcuni secondi mentre il bridge viene riconfigurato. Questi nuovi sistemi WiFi domestici con più ripetitori / extender fanno lo stesso. Ma se passi da una rete WiFi a un'altra mentre cammini per strada - se c'era il WiFi pubblico in tutti i negozi di fila - allora tutto va male. Ognuno di loro ti dà un nuovo indirizzo IP e ogni volta che il tuo indirizzo IP cambia, tutte le tue connessioni vengono interrotte.
LTE sta provando ancora di più. Mantieni il tuo indirizzo IP (di solito un indirizzo IPv6 nel caso delle reti mobili) anche quando ti muovi per miglia e più ripetitori cellulari ti trasferiscono da uno all'altro. Come? Beh... di solito si limitano a incanalare il traffico verso un punto centrale in cui è tutto collegato (sebbene attraverso un filtro firewall avanzato) in una rete virtuale di secondo livello super-enorme. E le tue connessioni continuano a vivere. A costo di molta complessità e una quantità davvero scoraggiante di latenza aggiuntiva che vorrebbero davvero rimuovere, ma è quasi impossibile.

Come far funzionare le reti mobili

Nota 1
si scopre che nulla in questa sezione richiede IPv6. Tutto funzionerebbe con IPv4 su NAT, anche il roaming su più NAT.
Ok, è stata una lunga storia, ma sono riuscito a tirarla fuori dalle persone dell'IETF. Quando siamo arrivati ​​qui, per il problema dell'IP mobile, non potevo fare altro che chiedere. Qualcosa è andato storto? Perché non riusciamo a farlo funzionare?
Si scopre che la risposta è sorprendentemente semplice. Il grosso difetto sta nel modo in cui è stato definito il noto "quattro" (IP sorgente, porta sorgente, IP destinazione, porta destinazione). Usiamo questo 4 per identificare una data sessione TCP o UDP; se il pacchetto contiene gli stessi quattro campi, allora appartiene a questa sessione e possiamo inviarlo al socket che serve la sessione. Ma il quattro copre due livelli: rete (terzo) e trasporti (quarto). Se invece definissimo le sessioni utilizzando solo dati Layer 4, i client mobili funzionerebbero bene.
Facciamo un breve esempio. La porta 1111 sul client X sta parlando con la porta 80 su Y, quindi dovrebbe inviare un quattro (X, 1111, Y, 80). La risposta arriva con (Y, 80, X, 1111) e il kernel la consegna al socket che ha creato il primo pacchetto. Quando X invia più pacchetti designati (X, 1111, Y, 80), Y li invia sullo stesso socket del server e così via.
Quindi X cambia il suo indirizzo IP e ottiene un nome, diciamo Q. Ora inizia a inviare pacchetti con un quattro (Q, 1111, Y, 80). Y non ha idea di cosa significhi e lo butta via. Nel frattempo, se Y invia pacchetti etichettati (Y, 80, X, 1111), allora vengono persi perché non c'è più X pronto a riceverli.
Immagina ora di taggare i socket senza legarli agli indirizzi IP. Perché funzioni, abbiamo bisogno di numeri di porta molto più grandi (che ora sono 16 bit). Facciamoli, diciamo, lunghi 128 o 256 bit, qualcosa come un hash univoco.
Ora X invia il pacchetto Y con etichetta (uuid, 80). Nota che i pacchetti stessi contengono ancora informazioni sugli indirizzi IP (X, Y), al livello 3 - questo è il modo in cui vengono instradati alla macchina corretta. Ma il kernel non usa le informazioni di livello 3 per decidere a quale socket inviare un pacchetto; usa solo uuid. La porta di destinazione (80 in questo caso) è necessaria solo per avviare una nuova sessione per determinare a quale servizio si desidera connettersi e può quindi essere ignorata o ignorata.
Per la direzione inversa, il kernel Y memorizza nella cache il fatto che i pacchetti per (uuid) vanno all'indirizzo IP X, che è l'ultimo indirizzo da cui provengono i pacchetti per (uuid).
Ora immagina che X cambi il suo indirizzo in Q. Invia ancora pacchetti etichettati (uuid, 80) all'indirizzo IP Y, ma ora questi pacchetti provengono dall'indirizzo Q. La macchina Y riceve questo pacchetto e lo confronta con il socket associato a ( uuid) , nota che i pacchetti per questo socket ora provengono dall'indirizzo Q e aggiorna la cache. Ora i pacchetti nella direzione opposta possono essere inviati, con il tag (uuid), nella direzione di Q invece di X. Tutto funziona! (Fatto salvo quanto necessario per prevenire attacchi di impostori).
Nota 2
Qualcuno ha chiesto come potrebbero essere queste "misure di prevenzione degli attacchi di connessione". Ci sono vari modi per farlo, ma il più semplice è fare qualcosa come lo scambio SYN-ACK-SYNACK che viene fatto all'avvio di TCP. Se Y si fida semplicemente del primo pacchetto dall'host Q, allora è troppo facile per un utente malintenzionato intercettare la connessione X-> Y inviando un pacchetto a Y da qualsiasi punto di Internet. (Anche se è un po' difficile indovinare quale uuid a 256 bit sostituire). Ma se Y restituisce un cookie che Q dovrebbe ricevere, elaborare e inviare, allora questo dimostrerà che Q è almeno un man-in-the-middle, e non solo un attaccante esterno (in ogni caso, TCP non garantisce anche tu di più). Se stai utilizzando un protocollo crittografato (come QUIC), l'handshake può essere protetto anche con una chiave di sessione.
C'è solo un problema: UDP e TCP non funzionano in questo modo ed è troppo tardi per aggiornarli. L'aggiornamento di UDP e TCP sarebbe paragonabile all'aggiornamento di IPv4 a IPv6; un progetto che sembrava semplice allora negli anni '90, ma decenni dopo non era nemmeno completato a metà (e la prima metà era semplice, il resto è molto più complicato).
La buona notizia è che potremmo essere in grado di aggirare questo problema con un'altra violazione della delaminazione. Se abbandoniamo il TCP - è comunque abbastanza vecchio - e usiamo invece QUIC su UDP, allora possiamo semplicemente smettere di usare il quadruplo UDP come identificatore di connessione. Invece, se il numero della porta UDP è un valore specifico che sta per "livello di mobilità", allora decomprimeremo il contenuto, che potrebbe essere un altro pacchetto con il tag UUID corretto, lo controlleremo rispetto alla sessione corretta e consegneremo quei pacchetti al presa corretta.
Ci sono notizie ancora migliori: il protocollo QUIC sperimentale ha già, almeno in teoria, la struttura del pacchetto corretta per funzionare in questo modo. Si scopre che sono comunque necessari identificatori di sessione univoci (chiavi) se si desidera utilizzare la crittografia e l'autenticazione senza stato come fa QUIC. Quindi, forse con piccole modifiche, QUIC potrebbe supportare il roaming trasparente. Che mondo come questo sarebbe!
Qui, tutto ciò che dobbiamo fare è rimuovere tutti i resti di UDP e TCP da Internet, e quindi perderemmo definitivamente la necessità di bridge di secondo livello, questa volta per davvero, e quindi potremmo sbarazzarci delle trasmissioni e degli indirizzi MAC e SDN e DHCP e tutto il resto.
Allora Internet sarebbe di nuovo aggraziato.