7. Supporto delle Reti Solo IPv6 con NAT64 e DNS64 (Supporting IPv6-Only Networks with NAT64 and DNS64)
Sebbene molti protocolli di transizione IPv6 siano stati standardizzati e distribuiti, la maggior parte sono trasparenti ai dispositivi client. L'uso combinato di NAT64 [RFC6146] e DNS64 [RFC6147] è una soluzione popolare che viene distribuita e richiede modifiche nei dispositivi client. Un possibile modo per gestire queste reti è che lo stack di rete del dispositivo client implementi 464XLAT [RFC6877]. 464XLAT ha il vantaggio di non richiedere modifiche al software dello spazio utente; tuttavia, richiede la traduzione per-pacchetto se l'applicazione utilizza letterali IPv4 e non incoraggia il software delle applicazioni client a supportare IPv6 nativo. Sulle piattaforme che non supportano 464XLAT, il motore Happy Eyeballs SHOULD seguire le raccomandazioni in questa sezione per supportare correttamente le reti solo IPv6 con NAT64 e DNS64.
Le funzionalità descritte in questa sezione SHOULD essere abilitate solo quando l'host rileva una di queste reti. Un'euristica semplice per ottenere ciò è verificare se la rete offre indirizzamento IPv6 instradabile, non offre indirizzamento IPv4 instradabile e offre un indirizzo resolver DNS.
7.1. Letterali di Indirizzi IPv4 (IPv4 Address Literals)
Se le applicazioni client o gli utenti desiderano connettersi a letterali di indirizzi IPv4, il motore Happy Eyeballs dovrà eseguire la sintesi dell'indirizzo NAT64 per loro. La soluzione è simile a "Bump-in-the-Host" [RFC6535] ma è implementata all'interno della libreria Happy Eyeballs.
Quando un indirizzo IPv4 viene passato alla libreria invece di un nome host, il dispositivo interroga la rete per il prefisso NAT64 utilizzando "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" (Scoperta del Prefisso IPv6 Utilizzato per la Sintesi di Indirizzi IPv6) [RFC7050] e quindi sintetizza un indirizzo IPv6 appropriato (o diversi) utilizzando la codifica descritta in "IPv6 Addressing of IPv4/IPv6 Translators" (Indirizzamento IPv6 dei Traduttori IPv4/IPv6) [RFC6052]. Gli indirizzi sintetizzati vengono quindi inseriti nell'elenco degli indirizzi come se fossero risultati di query DNS; i tentativi di connessione seguono l'algoritmo descritto sopra (vedere Sezione 5).
7.2. Nomi Host con Record AAAA Difettosi (Hostnames with Broken AAAA Records)
Al momento della stesura, esiste un numero piccolo ma non trascurabile di nomi host che si risolvono in record A validi e record AAAA difettosi, che definiamo come record AAAA che contengono indirizzi IPv6 apparentemente validi ma quegli indirizzi non rispondono mai quando contattati sulle porte usuali. Questi possono essere, ad esempio, causati da:
-
Errore di battitura dell'indirizzo IPv6 nella configurazione della zona DNS
-
Buchi neri di routing
-
Interruzioni del servizio
Mentre un algoritmo conforme alle altre sezioni di questo documento gestirebbe correttamente tali nomi host su una rete dual-stack, non funzioneranno necessariamente correttamente su reti solo IPv6 con NAT64 e DNS64. Poiché i resolver ricorsivi DNS64 si affidano ai server dei nomi autorevoli che inviano risposte negative ("nessun errore nessuna risposta") per i record AAAA per sintetizzare, non sintetizzeranno record per questi particolari nomi host e trasmetteranno invece il record AAAA difettoso.
Per supportare questi scenari, il dispositivo client deve interrogare il DNS per il record A e quindi eseguire la sintesi locale. Poiché questi tipi di nomi host sono rari e, per minimizzare il carico sui server DNS, questa query A dovrebbe essere eseguita solo quando il client ha rinunciato ai record AAAA che ha ricevuto inizialmente. Questo può essere ottenuto utilizzando un timeout più lungo, denominato "Last Resort Local Synthesis Delay" (Ritardo di Sintesi Locale di Ultima Risorsa); il ritardo è raccomandato essere di 2 secondi. Il timer viene avviato quando viene lanciato l'ultimo tentativo di connessione. Se nessun tentativo di connessione è riuscito quando questo timer si attiva, il dispositivo interroga il DNS per l'indirizzo IPv4 e, alla ricezione di un record A valido, lo tratta come se fosse fornito dall'applicazione (vedere Sezione 7.1).
7.3. Reti Private Virtuali (Virtual Private Networks)
Alcune reti private virtuali (Virtual Private Network, VPN) possono essere configurate per gestire le query DNS dal dispositivo. La configurazione potrebbe comprendere tutte le query o un sottoinsieme come "*.internal.example.com". Queste VPN possono anche essere configurate per instradare solo parte dello spazio di indirizzi IPv4, come 192.0.2.0/24. Tuttavia, se un nome host interno si risolve in un indirizzo IPv4 esterno, questi possono causare problemi se la rete sottostante è solo IPv6. Ad esempio, supponiamo che "www.internal.example.com" abbia esattamente un record A, 198.51.100.42, e nessun record AAAA. Il client invierà la query DNS al resolver ricorsivo dell'azienda e quel resolver risponderà con questi record. Il dispositivo ora ha solo un indirizzo IPv4 a cui connettersi e nessun percorso verso quell'indirizzo. Poiché il resolver dell'azienda non conosce il prefisso NAT64 della rete sottostante, non può sintetizzare l'indirizzo. Allo stesso modo, il resolver ricorsivo DNS64 della rete sottostante non conosce gli indirizzi interni dell'azienda, quindi non può risolvere il nome host. Per questo motivo, il dispositivo client deve risolvere il record A utilizzando il resolver dell'azienda e quindi sintetizzare localmente un indirizzo IPv6, come se l'indirizzo IPv4 risolto fosse fornito dall'applicazione (Sezione 7.1).