Grazie alle grandi collaborazioni globali come LHC, finalmente una luce in fondo al tunnel dell’eterna transizione a IPv6

Per lungo tempo si è parlato del passaggio a IPv6 come qualcosa di imminente ma poi, come sappiamo, le cose sono andate in modo diverso. Il passaggio al nuovo protocollo sta andando a rilento, complice l’affermarsi della tecnica del NAT che ha permesso di rendere molto meno pressante la richiesta di nuovi indirizzi IP pubblici per la maggior parte delle applicazioni.

Nel frattempo, la situazione sta cambiando per la necessità di collaborare con altre regioni del mondo e in ambito scientifico questo è specialmente vero per le grandi collaborazioni globali come LHC. Le prime attivazioni IPv6 di siti TIER risalgono al 2015, ma fino allo scorso anno le statistiche ne mostravano un utilizzo molto limitato. Poi con la scelta del CERN di equipaggiare i nodi di trasferimento dati con il doppio stack, vi è stata una vera esplosione dell’utilizzo e oggi circa il 50% del traffico scambiato con l’esterno viaggia su IPv6, mentre quello interno è anche maggiore. Oggi però non voglio parlare di questo, ma di quello che abbiamo scoperto al CNAF realizzando questo cambiamento.

Stefano Zani è responsabile del Reparto Rete e Servizi Informatici all’INFN-CNAF, vice responsabile del TIER1 e membro della Commissione Calcolo e Reti.

Quando abbiamo configurato IPv6 su varie parti della rete ci siamo imbattuti in alcuni limiti del protocollo e degli apparati con cui ci si trova a lavorare. Nessuno di questi problemi di per sé rappresenta un motivo per non cimentarvici, ma tutti insieme possono spiegare perché a una ventina d’anni dalla sua creazione IPv6 ancora fatica a decollare e la transizione a cui stiamo finalmente assistendo è qualcosa che sta avvenendo obtorto (proto)collo.

Il primo problema riscontrato è che non si riesce a fare una trasposizione 1 a 1 delle vecchie configurazioni IPv4 in IPv6, perché i due protocolli hanno filosofie un po’ diverse. Alla base di IPv6 c’era l’idea di massimizzare l’autoconfigurazione, che in teoria dovrebbe permettere una maggiore flessibilità ma, nel mondo reale può creare problemi a non finire. Ad esempio, dove in IPv4 avrei usato il DHCP per configurare un default gateway, in IPv6 non ho bisogno di questa informazione, potendo gestire le macchine in autoconfigurazione. Questo però significa che qualunque nodo può presentarsi come gateway per tutta la rete, ponendo una serie di potenziali problemi di sicurezza. Questo ci ha portati a rinunciare per il momento alla autoconfigurazione. Va detto che oggi disponiamo di ottimi strumenti di automazione, quindi configurare ogni singolo nodo non è un grosso problema, perché questo non avviene manualmente. Però è vero che abbiamo dovuto ripensare il modo in cui lavoravamo. “Sporcare” un po’ lo standard avrebbe permesso di passare da IPv4 a IPv6 in modo trasparente ma per almeno tre volte le proposte di modifiche in tal senso sono state rigettate dai “talebani” di IPv6, e questo purismo a mio avviso è stato uno dei motivi della sua difficoltà ad affermarsi.

Un altro non automatismo che rappresenta un’occasione persa è che, se su macchine configurate in dual stack per qualche motivo ci sono difficoltà sulla connettività su IPv6, non esiste un meccanismo automatico di fall back su IPv4. Bisogna capire se agendo sulla configurazione si possa risolvere il problema, o se vada fatto direttamente dal codice dell’applicazione.

Sembra banale, ma un aspetto che secondo me contribuisce alla percezione del nuovo protocollo come qualcosa di ostico è la “bruttezza” degli indirizzi IPv6. Mi spiego: un indirizzo IPv4 è breve, è puntato per facilitarne la lettura, ha una struttura riconoscibile; al contrario l’indirizzo IPv6 sembra un MAC address lungo ed è più difficile dargli un senso a colpo d’occhio, è pensato per le macchine ma non per gli esseri umani.

Ci sono aspetti più pratici, come la questione della compatibilità e delle performance dei router in utilizzo con IPv6. Gli apparati meno recenti sono dimensionati per la gestione di indirizzi a 32 bit. Ciò non significa che non lavorino in IPv6, ma possono avvenire cose inaspettate. Ad esempio noi spesso usiamo lunghe liste di ACL. Poiché gli indirizzi IPv6 sono più lunghi, può accadere che le risorse hardware (pensate in termini di IPv4) vengano saturate molto più velocemente. Quindi soprattutto con i router più datati possiamo credere di lavorare all’interno delle possibilità dell’apparato salvo poi scoprire che non è così. Ovviamente le nuove macchine non hanno di questi problemi, eppure spesso i numeri di targa sono ancora calcolati con lo sguardo a IPv4!

Sono convinto che se avessero fatto un IPv4 più lungo, anche con meno funzionalità, tutti lo avrebbero adottato da 15 anni. Va però finalmente anche spezzata una lancia in favore di IPv6: infatti, una volta superato il primo impatto, questo protocollo costituisce una tecnologia interessante e, se usato bene, presenta pochi problemi. È dotato anche una serie di funzionalità aggiuntive, ad esempio a livello di QoS, ma la verità è che oggi nessuno le usa. Lo stesso aumento di utilizzo a cui abbiamo assistito ultimamente è largamente indotto. Ad esempio nel caso di LHC, l’introduzione di nodi dual stack che fanno trasferimento dati aumenta in modo sostanziale il traffico. USA e CERN hanno guidato questa fase in modo quasi forzato e la ragione fondamentale è la necessità di garantire la collaborazione con l’Asia. Per quanto riguarda noi al CNAF, nel momento in cui lo abbiamo adottato la parte di divertimento con il nuovo protocollo ha prevalso sulla fatica di doverlo mettere in piedi e visto che l’appetito vien mangiando, magari ora con il nuovo data centre che stiamo realizzando qualcuna delle nuove funzionalità potrebbe essere utilizzata.

I maggiori casi d’uso di IPv6 fino a questo momento sono stati le applicazioni IoT e il trasporto su operatori asiatici che fondamentalmente gli indirizzi IPv4 non li hanno mai avuti. L’high-troughtput computing può essere un caso d’uso molto rilevante. Al CNAF non abbiamo mai usato indirizzi IP privati per i worker node e chi altrove lo ha fatto oggi è in crisi perché i modelli di calcolo sono sempre più globali: quindi il NAT, che è una soluzione validissima per l’IT tradizionale, crea problemi di performance non indifferenti quando si fa HTC.

Anche per quanto riguarda la sicurezza, non è vero come spesso si sente dire che vi sia un problema strutturale di protocollo: IPv6 se usato in modo appropriato non aumenta l’insicurezza della rete. In effetti i rischi sono più legati a come la rete viene configurata.

Concludendo, IPv6 è vivo e lotta insieme a noi e, con tutto quello che sta cambiando nel mondo delle reti oggi, passare alla nuova versione del protocollo non è certo l’aspetto più preoccupante, né quello più impegnativo. Ci sono ben altre sfide all’orizzonte sia per chi fa rete e basta sia per chi come noi fa soprattutto calcolo: tutta la parte cloud infatti si basa sulla rete e quindi non si può prescindere dalla sua evoluzione.