4. Soluzioni esistenti

4.1. Modalità tunnel IPsec

In un insieme limitato di circostanze, è possibile per un'implementazione in modalità tunnel IPsec, come quella descritta in [DHCP], attraversare NA(P)T con successo. Tuttavia, i requisiti per un attraversamento riuscito sono sufficientemente limitati da richiedere una soluzione più generale:

IPsec ESP. I tunnel IPsec ESP non coprono l'intestazione IP esterna all'interno del controllo di integrità del messaggio, e quindi non subiranno l'invalidazione dei dati di autenticazione a causa della traduzione dell'indirizzo. I tunnel IPsec non devono nemmeno preoccuparsi dell'invalidazione del checksum.
Nessuna validazione dell'indirizzo. La maggior parte delle attuali implementazioni in modalità tunnel IPsec non eseguono la validazione dell'indirizzo di origine, quindi le incompatibilità tra identificatori IKE e indirizzi di origine non verranno rilevate. Ciò introduce vulnerabilità di sicurezza come descritto nella Sezione 5.
Voci SPD "Any to Any". I client in modalità tunnel IPsec possono negoziare SPD "any to any", che non vengono invalidati dalla traduzione dell'indirizzo. Questo esclude effettivamente l'uso degli SPD per il filtraggio del traffico tunnel consentito.
Operazione a singolo client. Con solo un singolo client dietro un NAT, non c'è rischio di sovrapposizione degli SPD. Poiché il NAT non avrà bisogno di arbitrare tra client concorrenti, non c'è nemmeno rischio di traduzione errata della ri-chiave o demultiplexing improprio di SPI o cookie in arrivo.
Nessuna frammentazione. Quando viene utilizzata l'autenticazione tramite certificato, può verificarsi la frammentazione IKE. Questo può verificarsi quando vengono utilizzate catene di certificati, o anche quando si scambia un singolo certificato se la dimensione della chiave, o la dimensione di altri campi del certificato (come il nome distinto e altre estensioni), è sufficientemente grande. Tuttavia, quando vengono utilizzate chiavi pre-condivise per l'autenticazione, la frammentazione è meno probabile.
Sessioni attive. La maggior parte delle sessioni VPN mantiene tipicamente un flusso di traffico continuo durante la loro durata, in modo che le mappature delle porte UDP siano meno probabilmente rimosse a causa dell'inattività.

4.2. RSIP

RSIP, descritto in [RSIP] e [RSIPFrame], include meccanismi per l'attraversamento IPsec, come descritto in [RSIPsec]. Consentendo la comunicazione host-NA(P)T, RSIP affronta i problemi di demultiplexing SPI IPsec, così come la sovrapposizione SPD. È quindi adatto per l'uso in ambienti aziendali, così come in scenari di rete domestica. Consentendo agli host dietro un NAT di condividere l'indirizzo IP esterno del NA(P)T (il gateway RSIP), questo approccio è compatibile con protocolli che includono indirizzi IP incorporati.

Tunnelando i pacchetti IKE e IPsec, RSIP evita modifiche ai protocolli IKE e IPsec, sebbene siano necessarie modifiche importanti alle implementazioni IKE e IPsec dell'host per adattarle alla compatibilità RSIP. È quindi compatibile con tutti i protocolli esistenti (AH/ESP) e le modalità (trasporto e tunnel).

Per gestire il demultiplexing delle ri-chiavi IKE, RSIP richiede il flottamento della porta di origine IKE, così come la ri-chiave alla porta flottante. Di conseguenza, l'interoperabilità con le implementazioni IPsec esistenti non è assicurata.

RSIP non soddisfa i requisiti di distribuzione per una soluzione di compatibilità IPsec-NAT perché un host abilitato RSIP richiede un gateway abilitato RSIP corrispondente per stabilire una SA IPsec con un altro host. Poiché RSIP richiede modifiche solo ai client e ai router e non ai server, è meno difficile da distribuire rispetto a IPv6. Tuttavia, per i fornitori, l'implementazione di RSIP richiede una frazione sostanziale delle risorse richieste per il supporto IPv6. Pertanto, RSIP risolve un problema "transitorio" su una scala temporale a lungo termine, il che non è utile.

4.3. 6to4

6to4, come descritto in [RFC3056] può formare la base per una soluzione di attraversamento IPsec-NAT. In questo approccio, il NAT fornisce agli host IPv6 un prefisso IPv6 derivato dall'indirizzo IPv4 esterno del NAT, e incapsula i pacchetti IPv6 in IPv4 per la trasmissione ad altri host 6to4 o relay 6to4. Ciò consente a un host IPv6 che utilizza IPsec di comunicare liberamente con altri host all'interno delle cloud IPv6 o 6to4.

Sebbene 6to4 sia una soluzione elegante e robusta quando un singolo NA(P)T separa un client e un gateway VPN, non è universalmente applicabile. Poiché 6to4 richiede l'assegnazione di un indirizzo IPv4 instradabile al NA(P)T per consentire la formazione di un prefisso IPv6, non è utilizzabile quando esistono più NA(P)T tra il client e il gateway VPN. Ad esempio, un NA(P)T con un indirizzo privato sulla sua interfaccia esterna non può essere utilizzato dai client dietro di esso per ottenere un prefisso IPv6 tramite 6to4.

Sebbene 6to4 richieda poco supporto aggiuntivo dagli host che già supportano IPv6, richiede modifiche ai NAT, che devono essere aggiornati per supportare 6to4. Di conseguenza, 6to4 potrebbe non essere adatto per la distribuzione a breve termine.