3. Revisione delle Soluzioni di Mitigazione ND

La Tabella 1 riassume le soluzioni di mitigazione ND disponibili per i problemi 1-15 descritti nella Sezione 2.4. Soluzioni simili sono raggruppate, iniziando con quelle che affrontano il maggior numero di problemi.

Nella Tabella 1, i codici letterali indicano la categoria RFC (vedi BCP 9 [RFC2026]):

• S: Standards Track, E: Experimental, I: Informational, B: Best Current Practice, N/A: Not Applicable

Tabella 1: Soluzioni per i Problemi Identificati

Soluzione ND	Cat. RFC	Perf. Multicast	Affidab.	Sicur. Link	Esaur. NCE	Rit. Inol.	Resp. Indir.
		1	2	3	4	5	6
MBBv6	I	Risolve tutti i problemi identificati
FBBv6	N/A	Risolve tutti i problemi identificati
UPPH	I		X		X	X
WiND	S	Risolve tutti i problemi per reti LLN
SARP	E					X
ND TRILL	S					X
ND EVPN	S					X
RFC 7772	B		X
GRAND	S				X
SAVI/RA-G	I
RFC 6583	I
RFC 9686	S

3.1. Mobile Broadband IPv6 (MBBv6)

Le soluzioni IPv6 definite in [RFC6459], [RFC7066] e [RFC7278] per le reti mobili 3GPP sono indicate come MBBv6. Punti principali:

• Posiziona tutti gli host su link Point-to-Point (P2P) con il router, convertendo effettivamente tutti i multicast in unicast
• I link P2P non hanno indirizzi MAC, quindi Router-NCE-on-Demand è superfluo
• La fiducia in tutti i nodi riguarda solo il router; attraverso il filtraggio, gli host malevoli non possono causare danni
• Assegna un prefisso /64 univoco per ciascun host
• Mantiene binding (prefisso, interfaccia) per scopi di inoltro

Poiché tutte e tre le cause dei problemi ND sono affrontate, tutti i problemi discussi nella Sezione 2.4 sono risolti.

3.2. Fixed Broadband IPv6 (FBBv6)

La soluzione FBBv6 definita in [TR177] ha due varianti:

P2P: Tutti gli host su link P2P con il router. Funzionalmente simile a MBBv6, risolve tutti i problemi ND dalla Sezione 2.4.

P2MP: Tutti gli host su un link Point-to-Multipoint (P2MP) con il router, realizzato mediante:

• Posizionamento di tutti gli host in una singola VLAN sul router
• Configurazione del dispositivo di accesso (es. OLT) per bloccare l'inoltro frame tra porte di accesso
• Implementazione di DAD Proxy [RFC6957] sul router
• Assegnazione di un prefisso /64 univoco per host

Vantaggi:

• Il multicast host-to-router diventa effettivamente unicast
• La fiducia in tutti i nodi è limitata al router
• Il router installa preventivamente voci di inoltro, eliminando Router-NCE-on-Demand
• Il multicast router-to-host è limitato a RA non richiesti, inviati come unicast [RFC6085]

Risolve tutti i problemi ND dalla Sezione 2.4.

3.3. Unique Prefix per Host (UPPH)

Descritto in [RFC8273] e [RFC9663] (entrambi informativi). Migliora "isolamento host e gestione abbonati avanzata su segmenti di rete condivisi". Punti principali:

• Il router installa preventivamente voci di inoltro dopo l'assegnazione del prefisso, nessun Router-NCE-on-Demand
• Il multicast router-to-host è limitato a RA non richiesti, inviati come unicast
• Gli host inviano traffico tramite router, nessuna risoluzione indirizzo host-to-host

Previene problemi Router-NCE-on-Demand e multicast router-to-host.

[RFC8273] afferma: "Le reti con prefisso IPv6 univoco per host possono facilmente garantire che i dispositivi inviino pacchetti l'uno all'altro solo tramite router di primo hop." Tuttavia, su media condivisi (es. Ethernet) sono necessarie misure aggiuntive come Private VLANs [RFC5517]. Senza queste, gli host possono raggiungersi su L2 e causare problemi di fiducia in tutti i nodi e multicast host.

Dei problemi multicast host (problemi 1, 3, 5, 6, 7), UPPH previene problemi 5 e 7 (nessuna risoluzione host-to-host, nessun duplicato GUA), ma possono verificarsi problemi 1, 3, 6.

3.4. Wireless ND (WiND)

Il termine "WiND" descrive soluzioni ND fondamentalmente diverse per Low-Power and Lossy Networks (LLNs) [RFC7102], definite in [RFC6775], [RFC8505], [RFC8928] e [RFC8929] (Standards Track). WiND modifica il comportamento di host e router per utilizzare multicast solo per Router Discovery. Punti principali:

• Gli host registrano preventivamente gli indirizzi con unicast presso il router
• Il router comunica con gli host tramite unicast, diventando registrar astratto e arbitro della proprietà degli indirizzi
• Il router installa preventivamente NCE degli host, evitando risoluzione indirizzo host
• Il router imposta PIO L-Bit a 0; gli host comunicano solo con il router [RFC4861, Sezione 6.3.4]
• Ulteriori funzionalità specifiche per LLN

WiND affronta tutti i problemi ND (Sezione 2.4) per LLN. Tuttavia, il supporto WiND non è obbligatorio per gli host generici, quindi non disponibile come opzione di deployment senza vincoli aggiuntivi sui nodi partecipanti.

3.5. Scalable Address Resolution Protocol (SARP)

SARP [RFC7586] era una soluzione sperimentale (esperimento terminato nel 2017). Lo scenario d'uso sono data center con grandi domini L2 su più siti. In ciascun sito, più host (possibilmente VM) sono connessi a switch, che sono collegati in rete tramite reti L2 pure o overlay.

Gli switch:

• Effettuano snooping e installano tabelle proxy (IP, indirizzo MAC) per host locali
• Rispondono a richieste di risoluzione indirizzo da altri siti con il proprio indirizzo MAC
• Tutti gli host all'interno di un sito appaiono ad altri siti come un singolo indirizzo MAC
• Aggiungono risposte (IP, indirizzo MAC) da switch remoti a tabelle proxy ND per rispondere direttamente a future richieste locali

Riduce significativamente la dimensione della tabella indirizzi MAC degli switch e il numero di multicast di risoluzione indirizzo nella rete.

A differenza di MBBv6, FBBv6 e UPPH, SARP si concentra sulla riduzione del multicast di risoluzione indirizzo per migliorare prestazioni e scalabilità in domini L2 di dimensioni DC.

3.6. Ottimizzazione ND per TRILL

TRILL ARP and ND Optimization [RFC8302] (Standards Track) è simile a SARP (Sezione 3.5) e può essere considerata un'applicazione di SARP in ambienti TRILL.

Come SARP, l'ottimizzazione TRILL ND si concentra sulla riduzione del multicast di risoluzione indirizzo, affrontando il problema 5 (Sezione 2.1).

3.7. Proxy ND in Ethernet Virtual Private Networks (ND EVPN)

Proxy ARP/ND in EVPN è specificato in [RFC9161] (Standards Track). Lo scenario d'uso sono data center con grandi domini L2 su più siti. In ciascun sito, più host sono connessi a router Provider Edge (PE) collegati in rete tramite tunnel EVPN.

Ciascun PE del sito:

• Effettua snooping di NA di risoluzione indirizzo locali e costruisce voci tabella proxy ND (IP, indirizzo MAC)
• Propaga tali voci tramite BGP ad altri PE
• Effettua snooping di NS per host remoti da host locali
• Risponde direttamente se la voce host remoto esiste nella tabella proxy ND

Riduce significativamente il numero di messaggi multicast di risoluzione indirizzo.

Come SARP, anche Proxy ARP/ND in EVPN si concentra sulla riduzione del multicast di risoluzione indirizzo.

3.8. Riduzione Router Advertisement secondo RFC 7772

La connettività IPv6 richiede che gli host possano ricevere RA multicast periodici [RFC4861]. Gli host dormienti che elaborano pacchetti unicast devono anche elaborare RA multicast durante il sonno. RA eccessivi possono ridurre significativamente la durata della batteria degli host mobili.

[RFC7772] (Best Current Practice) specifica soluzioni per la riduzione RA:

• I router DOVREBBERO rispondere a RS con RA unicast (non RA multicast normale) quando indirizzo IP sorgente e indirizzo MAC dell'host sono specificati e validi (altri host non ricevono questo RA)
• I router DOVREBBERO ridurre la frequenza di RA multicast

[RFC7772] affronta il problema 2 (Sezione 2.1).

3.9. Gratuitous Neighbor Discovery (GRAND)

GRAND [RFC9131] (Standards Track) modifica ND come segue:

• Il nodo invia NA non richiesto quando assegna nuovo indirizzo IPv6 alla sua interfaccia
• Il router crea nuova NCE per questo nodo e imposta lo stato su STALE

Quando il pacchetto host arriva successivamente, il router può inoltrare immediatamente con NCE STALE esistente ([RFC4861], Sezione 7.2.2). Quindi invia NS unicast (non NS multicast per risoluzione indirizzo) per verifica raggiungibilità.

GRAND elimina il ritardo di inoltro del router, ma non risolve altri problemi Router-NCE-on-Demand (es. l'esaurimento NCE può ancora verificarsi).

3.10. Source Address Validation Improvement (SAVI) e Router Advertisement Guard (RA-Guard)

SAVI [RFC7039] (Informativo) lega indirizzi a porte switch L2 e rifiuta richieste da altre porte per quell'indirizzo. I nodi non possono spooffare indirizzi IP di altri nodi.

RA-Guard [RFC6105] [RFC7113] (Informativo) consente solo RA da porte a cui sono connessi router. I nodi su altre porte non possono impersonare router.

SAVI e RA-Guard affrontano problemi di sicurezza on-link.

3.11. Gestione Attacchi Esaurimento NCE secondo RFC 6583

[RFC6583] (Informativo) affronta il problema di attacco esaurimento NCE (Sezione 2.3). Raccomanda:

• Gli operatori DOVREBBERO:

  • Filtrare spazio indirizzi inutilizzato, in modo che messaggi a tali indirizzi vengano droppati anziché innescare creazione NCE
  • Implementare meccanismi di rate limiting per elaborazione messaggi ND per evitare sovraccarico CPU/memoria

• I fornitori DOVREBBERO:

  • Dare priorità all'elaborazione NDP di NCE esistenti rispetto alla creazione di nuove NCE

[RFC6583] riconosce: "Alcune di queste opzioni sono 'cerotti' e possono essere operativamente difficili da gestire." [RFC6583] affronta parzialmente il problema di esaurimento Router-NCE. In pratica, i fornitori di router impostano limiti superiori sul numero di NCE per interfaccia. Se il link ha più indirizzi, il router non può mantenere tutte le voci; i pacchetti verso indirizzi senza NCE vengono semplicemente droppati [RFC9663].

3.12. Registrazione Indirizzi IPv6 Auto-Generati Tramite DHCPv6 secondo RFC 9686

In IPv4, gli amministratori di rete possono recuperare indirizzi IP host dai server DHCP per gestione abbonati. In IPv6 con SLAAC, questo è impossibile (Sezione 2.3).

[RFC9686] (Standards Track) definisce un metodo per gli host per informare il server DHCPv6 di uno o più indirizzi auto-generati o configurati staticamente. Consente agli amministratori di rete di recuperare indirizzi IPv6 host dai server DHCPv6.

[RFC9686] fornisce una soluzione per il problema 15 (Sezione 2.3).

3.13. Enhanced DAD

Enhanced DAD [RFC7527] (Standards Track) affronta il problema di fallimento DAD in una situazione specifica: interfacce loopback. DAD fallisce su interfacce loopback perché l'host mittente riceve indietro il messaggio DAD e interpreta che un altro host desidera utilizzare lo stesso indirizzo.

Soluzione: Ogni messaggio DAD contiene opzione Nonce [RFC3971], consentendo all'host mittente di riconoscere che il messaggio DAD riflesso è stato inviato da se stesso.

Enhanced DAD non risolve alcun problema ND; estende ND per funzionare in un nuovo scenario (interfaccia loopback). Rivisto qui per completezza.

3.14. Mediazione ND per Interworking IP di VPN Layer 2

La mediazione ND è specificata in [RFC6575] (Standards Track). Quando due Attachment Circuits (AC) sono connessi tramite VPWS e hanno media diversi (es. uno Ethernet, altro Frame Relay), due PE devono cooperare per fornire servizio di mediazione affinché il CE possa risolvere l'indirizzo MAC dell'estremità remota.

La mediazione ND non affronta alcun problema ND; estende ND per funzionare in un nuovo scenario (due AC di media diversi connessi tramite VPWS). Rivisto qui per completezza.

3.15. Soluzioni ND Definite Prima delle Ultime Versioni di ND

Le ultime versioni ND e SLAAC sono specificate in [RFC4861] e [RFC4862]. Alcune mitigazioni ND sono state pubblicate prima di [RFC4861]. Riviste qui per completezza.

3.15.1. Secure Neighbor Discovery (SEND)

SEND [RFC3971] (Standards Track) mira a garantire che host e router siano affidabili. SEND ha definito tre nuove opzioni ND: Cryptographically Generated Addresses (CGA) [RFC3972] (Standards Track), crittografia a chiave pubblica RSA e Timestamp/Nonce. SEND ha anche definito il processo Authorization Delegation Discovery, meccanismo di prova proprietà indirizzo e requisiti per l'uso di questi componenti nel protocollo ND.

3.15.2. Cryptographically Generated Addresses (CGA)

Lo scopo di CGA è associare chiavi pubbliche crittografiche a indirizzi IPv6 nel protocollo SEND. Punto principale: calcolo dell'hash crittografico della chiave pubblica per generare l'Interface Identifier (IID) dell'indirizzo IPv6. L'indirizzo IPv6 risultante è chiamato CGA. La corrispondente chiave privata può essere utilizzata per firmare messaggi inviati dall'indirizzo.

CGA presume che l'host legittimo non si preoccupi della combinazione di bit IID creata dal procedimento hash. L'attaccante necessita dell'IID esatto per impersonare l'host legittimo, quindi affronta la sfida del calcolo hash inverso - una forte sfida matematica.

CGA fa parte di SEND. Nessun deployment riportato.

3.15.3. ND Proxy

ND Proxy [RFC4389] (Sperimentale) mira a far funzionare più link connessi tramite dispositivo proxy ND come un singolo link.

• Alla ricezione di richiesta ND da host su link, ND proxy effettua proxy del messaggio dall'interfaccia in uscita "migliore" (paragrafo successivo definisce). Se nessuna interfaccia migliore, ND proxy effettua proxy del messaggio a tutti gli altri link. Proxy significa: agisce come se il messaggio ND provenisse dal proxy ND stesso - cambia IP sorgente e MAC sorgente in IP e MAC dell'interfaccia in uscita e crea voce NCE sull'interfaccia in uscita di conseguenza.

• Alla ricezione di risposta ND, ND proxy agisce come se il messaggio ND fosse indirizzato a lui, aggiorna lo stato della voce NCE dell'interfaccia ricevente. Basandosi su tali informazioni di stato, ND proxy può determinare l'interfaccia in uscita "migliore" per future richieste ND. Quindi ND proxy effettua proxy del messaggio di ritorno all'host richiedente.

ND proxy è ampiamente utilizzato in SARP (Sezione 3.5), ottimizzazione TRILL ND (Sezione 3.6) e Proxy ARP/ND in EVPN (Sezione 3.7).

3.15.4. Optimistic DAD

Optimistic DAD [RFC4429] (Standards Track) mira a minimizzare il ritardo di configurazione indirizzo nel caso di successo e ridurre l'interruzione nel caso di fallimento il più possibile. Optimistic DAD consente all'host l'uso immediato dell'indirizzo appena formato per comunicare prima che DAD sia completato, presumendo che DAD avrà successo. Se l'indirizzo è duplicato, Optimistic DAD fornisce meccanismi per minimizzare l'impatto.

Optimistic DAD ha modificato l'ND originale [RFC2461] e il SLAAC originale [RFC2462] (entrambi obsoleti), ma la soluzione non è stata integrata nelle ultime specifiche ND e SLAAC [RFC4861] [RFC4862]. Tuttavia, esistono implementazioni di Optimistic DAD.

Optimistic DAD non risolve alcun problema ND (Sezione 2). Rivisto qui per completezza.

---