IPv6, crash-course

Francesco Prelz

INFN, sezione di Milano

per conto del gruppo d'interesse INFN per IPv6.

Cosa cambia, cosa resta uguale.

1. Per l'utente
   (che potrebbe non accorgersene)
   • IPv6 101, con ringraziamenti a Edoardo Martelli, CERN IT/CS.
2. Per l'amministratore di sistema e di rete
   (che ha paure non infondate)
   • Quali differenze semantiche per IPv6?
3. Per chi scrive o mantiene codice che usa la rete
   (che deve fare il grosso del lavoro ma non ne ha molta voglia).
• getaddrinfo() e compagnia.
• Gioie e dolori di RFC3484 → RFC6724.

IPv6 101 (1) - Indirizzi

Indirizzi IP:

IPv6 101 (2) - Sottoreti

Sottoreti:

IPv6 101 (3) - Famiglie di indirizzi

IPv6 101 (4) - Broadcast

IPv6 101 (5) - Multicast

IPv6 101 (6) - Header

Header IPv4	Header IPv6 (ma il diavolo è negli extension header!)

IPv6 101 (7) - Frammentazione

IPv6 101 (8) - Neighbor discovery

• Router Advertisement (RA): Pubblicazione periodica (in multicast!) della disponibilità di un router.
• Router Solicitation (RS): Un host comunica (in multicast) che ha bisogno immediatamente di conoscere l'indirizzo di un router (ad esempio al momento del boot).
• Neighbor Solicitation (NS): richiesta di conoscere l'indirizzo link-local di un host sullo stesso segmento di rete (equivalente ad una richiesta ARP).
  La richiesta viene inviata in multicast al solicited-node multicast address:
  FF02::1:FF + 24 bit meno significativi dell'indirizzo.
• Neighbor Advertisement (NA): risposta al pacchetto NS (equivalente alla risposta ARP).
• Redirect: Come in ICMPv6 è inviato da un router per informare un host che esiste una rotta migliore per raggiungere una determinata destinazione.

IPv6 101 (9) - Configurazione degli indirizzi

IPv6 101 (10) - SLAAC

IPv6 101 (11) - EUI-64

• Sia SLAAC che l'uso di DHCPv6 devono essere permessi dai messaggi di Router Advertisement (bit A del prefisso per SLAAC, bit M ed O dello header per DHCPv6).
  • Mentre però tutti i sistemi operativi onorano la richiesta di autoconfigurazione, per alcuni sistemi ed alcune versioni l'utilizzo di DHCPv6 va esplicitamente abilitato.
• Per autoconfigurarsi un indirizzo pubblico, gli host incollano normalmente ai 64 bit di prefisso altri 64 bit corrispondenti all'indirizzo EUI-64. Viene quindi applicato l'algoritmo di Duplicate Address Detection (DAD).
• A partire da un indirizzo Ethernet, alias EUI-48, l'indirizzo EUI-64 si ricava normalmente così:
  
  Indirizzo MAC:
  00 12 34 56 78 9A
  
  Si inserisce in mezzo FFFE:
  00 12 34 FF FE 56 78 9A
  
  Si inverte il settimo bit più significativo:
  02 12 34 FF FE 56 78 9A

IPv6 101 (12) - Protocolli di routing.

Principali differenze semantiche di IPv6 (1)

• Perlomeno l'indirizzo link-local oltre agli eventuali altri a scope globale.
• ⇒ Per ogni comunicazione di rete deve essere scelto un indirizzo di origine ed un indirizzo di destinazione.
• Queste preferenze sono nuovi parametri di configurazione dei sistemi. Per i dettagli vedi pù avanti.
• Sparisce la nozione di indirizzo 'principale' associato ad una interfaccia di rete (salvo che nel caso di Mobile IP, per il quale viene preferito lo Home Address).
• La questione se preferire IPv4 o IPv6 è un caso particolare di questo problema.
  • Mantenere in modo indolore la preferenza per IPv6 è cruciale per non far deragliare il treno della transizione.
  • Abbiamo già visto in opera alcune smentite di questo principio, purtroppo.
  • La questione è sostanzialmente nelle mani degli sviluppatori/manutentori di servizi e applicazioni, vedi anche qui più avanti.

Principali differenze semantiche di IPv6 (2)

• Può avvenire soltanto manualmente/staticamente o via Router Advertisement, e questi ultimi sono messaggi multicast sulla rete.
  • Modello opposto a quello di DHCP, push vs. pull.
• Ripetiamo: i Router Advertisement, che devono provenire da una sorgente legittima sulla rete (in caso contrario si aprono gli scenari descritti in RFC6104), inducono tutti gli host collegati ad un segmento di rete:
  • Ad abilitare o meno l'autoconfigurazione dell'indirizzo di rete (bit autonomous nell'annuncio dei prefissi).
  • A cercare altre informazioni attraverso una query a DHCPv6 (bit managed e other nei Router Advertisement).
  • Ad aggiungere alla loro tabella di routing un numero arbitrario di rotte, fra cui quella di default.
• Occorre avere una strategia per prevenire gli effetti di RA indesiderati (rogue). RA-guard (RFC6105), se implementato dalle parti attive di rete coinvolte, parrebbe il sistema più semplice.

Principali differenze semantiche di IPv6 (3)

• Oltre all'assegnazione manuale, sempre possibile, esistono meccanismi per rendere la configurazione del livello di trasporto semplice, automatica ed indolore (?):
  • Autoconfigurazione stateless o SLAAC (sostanzialmente: gli host aggiungono il loro MAC address ad un prefisso inviato in multicast dal router). Ma RFC6106, che permetterebbe di configurare i DNS via Router Advertisement, non pare essere ampiamente supportata.
  • Autoconfigurazione stateful o DHCPv6 (i clienti vengono identificati da due numeri generati a runtime: DUID che identifica l'host e IAID che identifica l'interfaccia). Come visto poco fa questo metodo non esenta dalla distribuzione dei Router Advertisement e quindi dalla protezione contro i rogue RA.
• Due esigenze fondamentali:
  1. Aggiornamento del DNS con la risoluzione inversa.
  2. Necessità di associare il traffico di rete ad un utente legittimo ed autorizzato (last-hop traceback).
     Art. 6 AUP GARR: "Tutti gli utenti a cui vengono forniti accessi alla Rete GARR devono essere riconosciuti ed identificabili".
• Ne riparliamo fra poco a proposito delle possibili strategie di transizione.

Differenze di IPv6 rilevanti per la sicurezza (1)

• RFC 4942 classifica tre ordini di caratteristiche (ma poi si concentra sul primo, visto che scrive agli estensori degli stack):
  1. Issues due to IPv6 protocol
  2. Issues due to Transition Mechanisms
  3. Issues due to IPv6 Deployment

Il protocollo richiede alle implementazioni di trattare extension header del protocollo per funzioni che in precedenza erano opzionali (IPsec, QOS, supporto per mobile IP) e reimplementa varie funzioni (DHCP, neighbor discovery, anycast, multicast). La comparsa di codice nuovo negli stack di rete è meravigliosa per chi è in cerca di vulnerabilità da sfruttare. Solo con l'avanzare dell'adozione e del tempo scopriremo quante ce ne sono.

Lo spazio di indirizzamento è più grande (128 bit - 340 undecilioni, 2120 indirizzi unicast teorici, 2112 indirizzi pubblici nella classe 2001:: già allocabili). Uno scan brute force è più laborioso, potrebbe essere saggio assegnare indirizzi non contigui, ma ci sono altri sistemi per trovare possibili target sulla rete locale. La collisione con indirizzi già allocati perde ogni efficacia (se mai ne ha avuta) nell'evidenziare accessi non autorizzati.

Differenze di IPv6 rilevanti per la sicurezza (2)

Molte funzioni utili al protocollo (Neighbor Discovery, MTU discovery, Mobility) vengono assorbite a livello 3 in ICMPv6. Dunque la comunicazione a livello 3 deve funzionare automaticamente almeno per macchine sullo stesso link. Molti tipi di messaggi nuovi in ICMPv6, ed una RFC (4890) dedicata solo a specificare regole di firewall minimali per gli accessi IPv6. L'operazione di Neighbor Discovery richiede un multicast locale. Ma ICMPv6 proibisce esplicitamente di rispondere a/amplificare richieste inviate a indirizzi multicast (es: FF02::1, all-link-local-nodes, FF05::2, all-routers, vedi RFC2373).

I dispositivi intermedi non possono frammentare i pacchetti. La MTU minima è di 1280 byte. Nessuno però impedisce alle implementazione degli stack di creare autolesionisticamente frammenti più piccoli.

Differenze di IPv6 rilevanti per la sicurezza (3)

	Ma... La grande quantità di header opzionali del protocollo potrebbe significare che il payload di livello superiore (con numeri di porta, ed altre informazioni utili per filtri e firewall) non si trova nel primo frammento e richiede di riassemblare i pacchetti.
	A conclusione e parziale giustificazione di questo (preoccupante?) elenco di differenze, ricordiamo le tensioni in gioco nella progettazione di IPv6: Recuperare la trasparenza interna del livello di trasporto (soppressione di qualunque elemento intermedio stateful: NAT, Firewall). Facilitare la configurazione automatica del livello di trasporto. Consentire applicazioni di IP mobile.

La transizione IPv4→IPv6.

Scenario di transizione con host solo IPv6 (?) (1)

Scenario di transizione con host solo IPv6 (?) (2)

Della transizione: princìpi-guida.

1. I servizi su IPv6 devono funzionare da subito tanto bene quanto i loro equivalenti su IPv4:
   • ⇒ "IPv6 days" in cui si ha il permesso di rompere qualcosa.
   • ¬⇒ che l'indirizzo dell ambìto web server ec.europa.eu cominci ad essere risolto su IPv6 senza essere raggiungibile via IPv6, come avvenuto il 6 Maggio 2014!
2. Occorre mantenere ovunque la preferenza per IPv6.
   • Ogni eccezione è un sassolino che rallenta il treno della migrazione.
3. Non bisogna avere fretta, ma agire proattivamente.
   • Gli strumenti di gestione della rete e di monitoring devono essere aggiornati.
   • Uno dei principali scenari problematici per la sicurezza è che le applicazioni vengano rappezzate in fretta e senza adeguata sperimentazione.
4. Occorre resistere allo scoraggiamento, la transizione sta avvenendo.
   • "At Google we believe IPv6 is essential to the continued health and growth of the Internet".
   • "Replacing the Internet's plumbing will take some time, but the transition has begun".
   • Le statistiche di Google mostrano (per ora) un raddoppio ogni anno.
     Ora è il 10%, un anno fa il 5%, due anni fa il 2.5%...

getaddrinfo() e compagnia

1. gethostbyname()/getservbyname() → getaddrinfo()
2. gethostbyaddr()/getservbyport() → getnameinfo()
3. sockaddr_in(6) → sockaddr_storage
4. Usi espliciti di struct in_addr senza casi paralleli per IPv6
5. Manipolazioni di contenuti di sockaddr senza casi paralleli per IPv6
6. inet_aton() → inet_pton()
7. inet_ntoa() → inet_ntop()

getaddrinfo() - esempio

  #include <sys/socket.h>
  #include <netdb.h>
  char *destination, *service; /* Both can be numeric (address,port). */
  struct addrinfo ai_req, *ai_ans, *cur_ans;
 
  ai_req.ai_flags = 0;
  ai_req.ai_family = PF_UNSPEC;
  ai_req.ai_socktype = SOCK_STREAM;
  ai_req.ai_protocol = 0; /* Any protocol is OK */

  if (getaddrinfo(destination, service, &ai_req, &ai_ans)) == 0) {
    for (cur_ans = ai_ans; cur_ans != NULL; cur_ans = cur_ans->ai_next) {
      int fd_socket;
      if ((fd_socket=socket(cur_ans->ai_family, cur_ans->ai_socktype,
                            cur_ans->ai_protocol)) < 0) next;
      /* Do-what-needs-to-be-done. */
      break;
    }
  } else .....

Scelta degli indirizzi di origine e destinazione.

• La scelta di un indirizzo (e di una address family) di destinazione è normalmente nelle mani degli sviluppatori delle applicazioni:
  • I risultati delle query al DNS fatte via getaddrinfo() sono ordinati come indicato in RFC 6724;
  • DOVREBBERO perlomeno esaminati tutti con un ciclo opportuno!
  • operando un appropriato fall-back in caso di fallimenti. (Attenzione: potrebbe essere costoso! Ci ritorneremo).
• La scelta dell'indirizzo di origine quando si sta iniziando a comunicare via IP è molto spesso lasciata al sistema operativo (non viene effettuata nessuna chiamata esplicita a bind(2)).
• La scelta di un indirizzo e di una address family locale di listen è molto spesso lasciata non precisata.
  Questa scelta è considerata "out of RFC6724 scope" (§ 2), ma la glibc utilizza RFC3484 (la versione precedente della RFC) proprio per questo scopo!

La master policy table di RFC6724.

/etc/gai.conf, ip -6 addrlabel e compagnia bella.

• Il sistema meno cervellotico per permettere all'amministratore di configurare questa tabella è stato di esporla tale e quale, nello stesso formato utilizzato nella RFC:
  • Sia per la scelta dell'indirizzo di destinazione (/etc/gai.conf su Linux)
  • che per la scelta dell'indirizzo di origine: ip -6 addrlabel show:
    prefix ::1/128 label 0
prefix ::/96 label 3
prefix ::ffff:0.0.0.0/96 label 4
prefix 2001::/32 label 6
prefix 2001:10::/28 label 7
prefix 2002::/16 label 2
prefix fc00::/7 label 5
prefix ::/0 label 1
    
• Su FreeBSD esiste un comando ip6addrctl, ereditato dallo stack KAME, che gestisce entrambe le preferenze (origine e destinazione), e fornisce un utile contatore dell'uso delle regole.
  → ma MacOS non ha ancora incluso questo comando!
• Su Windows:
  netsh int ipv6 show[/set/add/delete] pre[fixpolicy].

Caso clinico #1: Credevo-che-avrebbe-usato-IPv4.

1. Avete sentito dire che abilitare il dual stack IPV4/IPv6 sui servizi centrali è una cosa buona, allora correte a farlo sul mail exchanger principale:
   mi.infn.it mail exchanger = 10 smtp1.mi.infn.it.
smtp1.mi.infn.it has address 192.84.138.69
smtp1.mi.infn.it has IPv6 address 2001:760:4210:1::a.
2. Il MX inizia a ricevere posta da nodi sulla stessa sottorete che non hanno nessuna configurazione di IPv6, ma solo lo stack acceso:
   Mar 15 05:01:31 smtp1 sendmail[1244]: (...) relay=[IPv6:fe80::21d:9ff:fe10:faf9]
3. IPv6 viene normalmente preferito a IPv4, così quando si scopre che l'indirizzo di destinazione appartiene ad un prefisso IPv6 'on-link' (cosa nota via Router Advertisement), la comunicazione può felicemente avvenire via IPv6, utilizzando lo scope link-local:
   fe80::20e:cff:fe4c:1ea5 lladdr 00:0e:0c:4c:1e:a5 REACHABLE
2001:760:4210:1::a      lladdr 00:0e:0c:4c:1e:a5 REACHABLE
4. Le cose potrebbero complicarsi se l'MX parla con office365, che da qualche mese differenzia le policy richiedendo obbligatoriamente SPF o DKIM per IPv6...

Caso clinico #2: l'indirizzo 6to4 e la rotta di default.

Caso clinico #3: l'indirizzo locale preferito.

1. Su un host IPv6 provvisto di indirizzo IPv6 pubblico tutto funziona a meraviglia.
2. Finché qualcuno decide di aggiungere un altro indirizzo pubblico, che viene messo in ordine prima dell'indirizzo a cui punta la risoluzione nel DNS:
   inet6 2001:760:4210:1::da:da01/64 scope global valid_lft forever
inet6 2001:760:4210:1::d/64 scope global valid_lft forever.
3. Improvvisamente, le verifiche dello hostname per le connessioni SSL che originano dalla macchina iniziano a fallire, perché il traffico ha origine dal nuovo indirizzo appena aggiunto, preferito dal sistema operativo.
4. Soluzione: manipolare la tabella di preferenza dei prefissi per gli indirizzo di origine:
   prefix 2001:760:4210:1::da:0/112 label 8.
5. Oppure assicurarsi che tutti i servizi registrino (bind()) le socket utilizzate per l'invio ad uno specifico indirizzo...

Caso clinico #4: il listener dual-stack.

1. Nei sistemi con stack di rete ibrido IPv6/IPv4 (ad es. Linux), i servizi che cercano di chiamare bind() all'indirizzo IPv6 'unspecified' (:: - tutti zeri) si troveranno felicemente registrati sia su IPv6 che su IPv4 (a meno che utilizzino l'apposita opzione di setsockopt IPV6_V6ONLY).
2. Solitamente però le socket in ascolto vengono ottenute richiedendo una socket passiva nella address family PF_UNSPEC.
3. Glibc risponde a tale richiesta con un indirizzo di origine che risulti preferito per collegarsi alla destinazione localhost secondo le regole di RFC3484, che è stata resa obsoleta da RFC6724, che, come visto, afferma di non applicarsi a questo caso.
4. La chiamata fino a qualche tempo fa restituiva una socket in listen su entrambi gli stack listening socket. Tuttavia un commit del 2008 su glibc ha corretto un baco: all'indirizzo IPv6 'localhost' (::1) non veniva assegnato lo scope link-local, come richiesto da RFC4291.
5. Risultato: dal momento che nelle regole di default di RFC6724 l'indirizzo IPV4 di localhost ha la stessa 'label' di tutto il resto di IPv4 ora, senza cambiare una riga di codice, viene preferito un binding solo su IPv4!

Palle degli occhi felici ?

• C'è chi crede che fare fall-back da un protocollo che non funziona ad uno che funziona (che sia IPv4 o IPv6) attendendo i timeout del caso sia troppo costoso.
  • Allora è stato inventato, specificato in RFC6555 e implementato in alcuni clienti (Chrome, Firefox) l'algoritmo Happy Eyeballs.
• Questo però è di aiuto solo se uno dei due protocolli è rotto: come abbiamo detto, IPv6 deve funzionare almeno bene come il suo predecessore, ed essere aggiustato con la stessa tempestività, se vogliamo che si espanda senza essere notato troppo.
• Il vero modo per restare felici è capitalizzare sul fatto che le nostre NREN sono pronte per IPv6 da anni e fare in modo che il treno della transizione si muova lentamente ma inesorabilmente in avanti. Tutti potete aiutare!

Bibliografia

• Knowledge base del gruppo di lavoro IPv6 di HEPix: http://hepix-ipv6.web.cern.ch/knowledge-base.
• Scott Hogg, Eric Vyncke, "IPv6 Security", Cisco Press, Gennaio 2009.
• Microsoft, "IPv6 Security Considerations and Recommendations ", aggiornato ad Agosto 2011
• Una pletora di RFC: 2373, 2375, 2460, 2461, 2463, 2766, 3041, 3315, 3484, 3971, 4191, 4291, 4860, 4861, 4862, 4890, 4942, 4966, 6104. 6106. 6724.