Perché l’addressing plan IPv6 è una scelta di design, non di configurazione

In ENSLD la progettazione dell’indirizzamento IPv6 non riguarda “far funzionare i ping”, ma costruire un piano gerarchico e sommarizzabile che sopravviva alla crescita dell’azienda. La superficie enorme dello spazio (un /48 contiene 65.536 subnet /64) è un’opportunità per allineare i confini di indirizzamento a quelli topologici, ma diventa un problema se si sub-nettizza a caso.

Blocchi di prefisso e il ruolo del /64

La regola cardine: la subnet standard IPv6 è sempre un /64. È un requisito, non una convenzione: SLAAC e l’interface identifier a 64 bit (EUI-64) presuppongono 64 bit di host. Assegnare /64 a ogni link (LAN, transito, e per prassi anche i loopback) è la scelta di design corretta.

Il provider tipicamente delega un /48 al sito, che lascia 16 bit di subnetting interni. Questi 16 bit sono la vera leva di design: vanno spesi in modo gerarchico, non sequenziale.

Livello gerarchico Bit dedicati Risultato
Site prefix (da ISP/RIR) /48 Blocco aziendale
Regione / campus +2-4 bit Es. /52 per area
Building / blocco funzionale +4 bit Es. /56
Subnet di accesso fino a /64 VLAN, link

Esempio di allocazione strutturata (concettuale): riservare i bit più significativi del campo subnet alla regione geografica, i successivi al sito, gli ultimi al tipo di rete (dati, voce, management, wireless). Così ogni sito è sommarizzabile in un solo prefisso verso il core.

Subnetting gerarchico e sommarizzazione

Il punto d’esame più ricorrente: un piano piatto (subnet consecutive senza allineamento) impedisce la summarization e gonfia le tabelle di routing. Un piano gerarchico permette a un router di frontiera di annunciare un unico aggregato (es. 2001:db8:ab00::/40 per un’intera regione) invece di centinaia di /64. Lasciare spazio di crescita (bit non assegnati) tra i blocchi è deliberato: consente di espandere un sito senza rompere l’aggregazione. Allineare i confini di summarization ai confini di area OSPFv3 o alle boundary EIGRP è la best practice di design.

Strategie di migrazione: quale in quale scenario

Dual-stack — l’approccio preferito

Dual-stack significa IPv4 e IPv6 attivi simultaneamente sulla stessa interfaccia; ogni nodo sceglie il protocollo in base a DNS e Happy Eyeballs. In ENSLD è l’opzione raccomandata end-to-end quando l’infrastruttura (hardware, IOS/IOS-XE, applicazioni) supporta nativamente IPv6.

Vantaggi: nessun overhead di incapsulamento, path ottimale, troubleshooting nativo, nessun single point of failure di traduzione/tunnel. Svantaggi: richiede supporto IPv6 ovunque, raddoppia gli oggetti da gestire (due tabelle di routing, due set di ACL/security policy).

Tunneling — soluzione transitoria

Serve quando “isole” IPv6 devono attraversare un core solo-IPv4.

  • Manual / GRE tunnel: punto-punto, statici, deterministici. Ideali fra due siti noti; scalano male (full mesh N²).
  • 6to4: automatico, usa il prefisso 2002::/16 derivato dall’indirizzo IPv4. Considerato legacy/deprecato per instabilità e dipendenza da relay pubblici.

Il tunneling aggiunge overhead di incapsulamento (MTU/frammentazione, PMTUD), complica il troubleshooting e crea colli di bottiglia. È una tappa di transizione, non una destinazione.

Traduzione — NAT64

NAT64 (con DNS64) permette a client solo-IPv6 di raggiungere server solo-IPv4. Il prefisso well-known è 64:ff9b::/96. Scenario tipico: rete di accesso moderna IPv6-only che deve ancora consumare servizi legacy IPv4. È traduzione stateful e asimmetrica (non pensata per connessioni IPv4→IPv6 iniziate dall’esterno).

Confronto sintetico

Criterio Dual-stack Tunneling NAT64
Preferenza di design Alta Bassa Media (caso specifico)
Overhead Nessuno Incapsulamento/MTU Traduzione stateful
Path ottimale Sì No Parziale
Uso Target finale Transitorio IPv6-only ↔ IPv4

Impatto su routing e sommarizzabilità

Con dual-stack si usano OSPFv3 o EIGRP for IPv6 (address-family); MP-BGP trasporta la famiglia ipv6 unicast separatamente da IPv4. Un piano gerarchico rende gli aggregati IPv6 stabili e riduce il churn. Il tunneling invece spezza la contiguità dei prefissi (le isole non sono adiacenti), rendendo la summarization difficile o impossibile e forzando route più specifiche.

Trappole tipiche d’esame

  • Scenario: assegnano un /64 a una LAN e chiedono se conviene un /112 per risparmiare → Risposta giusta: mantenere /64; SLAAC/EUI-64 lo richiede, il risparmio è inutile e rompe l’autoconfigurazione.
  • Scenario: azienda con supporto IPv6 nativo end-to-end, chiedono la strategia di migrazione → Risposta giusta: dual-stack, non tunneling né NAT64 (preferito quando tutto supporta IPv6).
  • Scenario: client IPv6-only devono raggiungere applicazioni legacy IPv4 → Risposta giusta: NAT64 + DNS64, non 6to4.
  • Scenario: tabelle di routing IPv6 gonfie con centinaia di /64 verso il core → Risposta giusta: piano gerarchico allineato ai confini di area con summarization, riservando bit di crescita.
  • Scenario: proposta di 6to4 per una nuova rete di transito → Risposta giusta: evitarlo (legacy/instabile, dipende da relay); usare tunnel GRE/manuali o, meglio, dual-stack.