Come prevenire i ritardi associati ai record AAAA IPv6?

I nostri server Windows stanno registrando i AAAArecord IPv6 con i nostri server DNS Windows. Tuttavia, non abbiamo abilitato il routing IPv6 sulla nostra rete, quindi questo spesso causa comportamenti di stallo.

Microsoft RDP è il peggior trasgressore. Quando si connette a un server che ha un AAAArecord in DNS, il client desktop remoto proverà prima IPv6 e non tornerà a IPv4 fino al timeout della connessione. Gli utenti esperti possono aggirare il problema collegandosi direttamente all'indirizzo IP. La risoluzione dell'indirizzo IPv4 con ping -4 hostname.foofunziona sempre all'istante.

Cosa posso fare per evitare questo ritardo?

• Disabilitare IPv6 sul client?
  • No, Microsoft afferma che IPv6 è una parte obbligatoria del sistema operativo Windows.
  • Troppi clienti per garantire che questo sia impostato ovunque in modo coerente.
  • Causerà più problemi in seguito quando finalmente implementeremo IPv6.
• Disabilitare IPv6 sul server?
  • No, Microsoft afferma che IPv6 è una parte obbligatoria del sistema operativo Windows.
  • Richiede un trucco del registro scomodo per disabilitare l'intero stack IPv6.
  • Accertarsi che sia impostato correttamente su tutti i server è scomodo.
  • Causerà più problemi in seguito quando finalmente implementeremo IPv6.
• Maschera record IPv6 sul ricursore DNS facnig dell'utente?
  • No, stiamo usando NLNet Unbound e non lo supporta .
• Impedire la registrazione dei record AAAA IPv6 sul server DNS Microsoft?
  • Non penso sia nemmeno possibile.

A questo punto, sto pensando di scrivere una sceneggiatura che cancella tutti i record AAAA dalle nostre zone DNS. Per favore, aiutami a trovare un modo migliore.

AGGIORNAMENTO: la risoluzione DNS non è il problema. Come sottolinea @joeqwerty nella sua risposta, i record DNS vengono restituiti all'istante. Entrambi Ae i AAAArecord sono immediatamente disponibili. Il problema è che alcuni client ( mstsc.exe) tenteranno preferibilmente una connessione su IPv6 e impiegheranno un po 'a ricorrere a IPv4.

Sembra un problema di routing. Il pingcomando produce un messaggio di errore "Errore generale" perché l'indirizzo di destinazione non è eseguibile.

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Non riesco ad acquisire un pacchetto di questo comportamento. L'esecuzione di questo comando ping (non riuscito) non produce alcun pacchetto in Microsoft Network Monitor. Allo stesso modo, tentare una connessione con mstsc.exeun host con un AAAArecord non produce traffico fino a quando non esegue un fallback a IPv4.

AGGIORNAMENTO: tutti i nostri host utilizzano indirizzi IPv4 instradabili pubblicamente. Penso che questo problema potrebbe dipendere da una configurazione 6to4 non funzionante. 6to4 si comporta in modo diverso sugli host con indirizzi IP pubblici rispetto agli indirizzi RFC1918.

AGGIORNAMENTO: C'è sicuramente qualcosa di sospetto con 6to4 sulla mia rete. Quando disabilito 6to4 sul client Windows, le connessioni si risolvono istantaneamente.

netsh int ipv6 6to4 set state disabled

Ma come dice @joeqwerty, questo maschera solo il problema. Sto ancora cercando di scoprire perché la comunicazione IPv6 sulla nostra rete è completamente non funzionante.

Questa domanda è piuttosto interessante e devo ammettere che non ho mai visto questo comportamento. Nel fare un po 'di giocherellando per cercare di capirlo meglio, ho preso un frammento di query nslookup per uno dei miei server RDS W2K8R2 da un altro server W2K8R2 e ho anche catturato un frammento di una sessione RDP sullo stesso server RDS dallo stesso server di test . Nslookup non ha mostrato alcun ritardo nella restituzione del record IPv6 e nslookup ha mostrato che il mio server di test esegue una query per il record IPv4 prima di eseguire una query per il record IPv6. Il delta temporale nell'acquisizione non mostra alcun ritardo apprezzabile (che posso accertare) in entrambe le query.

MODIFICARE

Ora stai per qualcosa.

Assicurati di acquisire il traffico per l'adattatore Microsoft 6To4, altrimenti non vedrai IPv6:

Ecco il risultato di nslookup per il mio server RDS. Prendi nota degli indirizzi IPv6:

Ora ecco un frammento della mia cattura:

E infine, ecco un frammento di netstat che mostra la connessione:

Così chiaramente, come hai confermato, la risoluzione DNS non è il problema. Il problema è che la connessione RDP preferisce IPv6 su IPv4 (che è l'impostazione predefinita per Windows - Windows preferisce IPv6 su IPv4) e poiché IPv6 non funziona correttamente sta causando il ritardo (come hai detto) quando si passa da IPv6 a IPv4. È possibile risolvere questo problema configurando i client in modo da preferire IPv4 rispetto a IPv6, ma penso che sarebbe semplicemente mascherare il problema. La soluzione migliore sarebbe capire perché IPv6 non funziona e risolverlo. Non so abbastanza su IPv6 per aiutare, ma la mia ipotesi è che i record IPv6 restituiti dal DNS siano indirizzi "locali" validi solo sulla sottorete in cui sono presenti gli host RDS e poiché i client si trovano in una sottorete diversa, possono " t raggiungere quegli indirizzi IPv6.

La tecnologia di transizione IPv6 chiamato 6to4 è famigerato per aver causato problemi come questo. Ci sono diversi fattori al lavoro. Individualmente sono innocui, ma l'effetto combinato è che gli utenti finali possono sperimentare ritardi di connessione.

Un elenco di fattori abilitanti e pensieri sulla loro mitigazione è presentato di seguito.

Windows abilita 6to4 per impostazione predefinita

Se i tuoi host eseguono una versione recente di Windows (Vista o successiva), Windows abiliterà opportunisticamente il tunneling 6to4 quando è disponibile un indirizzo IPv4 instradabile pubblicamente. Criticamente, questo vale sia per i server che per i client.

Per scoprire se un sistema utilizza 6to4, esegui ipconfige cerca un indirizzo IPv6 che inizi con il prefisso 6to4 2002:. Sembrerebbe qualcosa del genere.

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222

• Se i tuoi endpoint sono connessi ad Active Directory, puoi utilizzare Criteri di gruppo per disabilitare i protocolli di transizione come 6to4 e Teredo. Questo è ben documentato in KB929852 . (Applicare questo ai tuoi client o server sarebbe sufficiente, ma se stai facendo questo passo probabilmente ha senso disabilitarlo ovunque, sia su client che su server.)
• Se gestisci solo pochi host, puoi disabilitare 6to4 caso per caso. È molto meglio che disabilitare completamente IPv6.netsh int ipv6 6to4 set state disabled
• Utilizzare un sistema operativo client diverso. Ad esempio, Mac OS X non ha 6to4 abilitato per impostazione predefinita.

Vengono utilizzati indirizzi IPv4 pubblicamente instradabili

6to4 funziona solo su host con indirizzi IPv4 instradabili pubblicamente, quindi questo problema non influisce mai sugli host dietro un firewall NAT.

• È possibile spostare client e / o server dietro un firewall NAT e iniziare a utilizzare l'indirizzamento RFC1918. Ma in alcuni casi, in realtà sono preferiti indirizzi indirizzabili pubblicamente. Cambiare l'indirizzamento di un'intera rete potrebbe anche essere una scelta non realistica.

6to4 non funziona correttamente sulla rete

È incredibilmente difficile risolvere 6to4 in qualsiasi modalità di trasmissione. È così problematico che all'IETF è stata presentata una richiesta formale che il 6to4 dovesse essere riclassificato come storico . Secondo l'opinione di questo autore, 6to4 è stato deprecato.

In breve, 6to4 funziona incapsulando i pacchetti IPv6 in pacchetti IPv4 usando un protocollo chiamato 6in4 (protocollo IP = 41). I pacchetti IPv4 sono indirizzati a qualsiasi indirizzo broadcast 192.88.99.1nella speranza che arrivi a un relay 6to4 funzionante da qualche parte su Internet. Potrebbe anche essere geograficamente nelle vicinanze, se sei fortunato.

In pratica, alcuni relè 6to4 sono impostati in modo errato e molte reti non consentono nemmeno al traffico 6in4 di attraversare il firewall. In genere ciò accade quando un firewall consente tutto il traffico in uscita, ma non consente esplicitamente ai pacchetti del protocollo IP 41 di tornare attraverso il firewall. (TODO nota la RFC pertinente per la risoluzione dei problemi.) Questo errore ("buco nero in entrata") e molti altri sono descritti in RFC 6343 .

• Configurare il firewall in modo da rifiutare fortemente il protocollo IP 41 (con reset TCP) quando inviato dagli host interni alla rete. Ciò dovrebbe comportare un comportamento "fail fast" che ha più senso dei ritardi di connessione non deterministici. Questo ha dimostrato di funzionare in ambienti di test limitati .
• Chiedere al proprio ISP o al fornitore di transito di primo passaggio di impostare un relè 6to4 funzionante. Se fatto correttamente, si otterrà la migliore esperienza per gli utenti finali. Qualsiasi utente finale con un indirizzo IPv4 instradabile pubblicamente sarebbe in grado di partecipare a Internet IPv6.

Registrazione DNS dinamica

In un tipico ambiente di Active Directory, ogni computer è autorizzato a registrare i propri indirizzi con il server DNS. Quando un host è multihomed, registrerà tutti i suoi indirizzi, anche da un tunnel 6to4.

La maggior parte dei servizi Internet non utilizza DNS dinamico, quindi questo problema è in genere limitato ai siti aziendali in cui client e server sono tutti "interni" alla stessa rete.

• Puoi scegliere di disabilitare gli aggiornamenti DNS dinamici. Quindi se non si inseriscono record di risorse AAAA nel file di zona, questi non verranno mai pubblicati. Tuttavia, il DNS dinamico è spesso desiderabile per i server DNS interni. (Se lo fai, assicurati di eliminare anche tutti i record AAAA che potrebbero essere già presenti.)
• Configurare il server DNS per non fornire risposte per i record di risorse AAAA. Ma non farlo, perché ti darà davvero dei problemi quando vuoi iniziare a implementare IPv6. (Qualcuno sa di un firewall DNS gratuito / open source?)

L'applicazione client non viene eseguita correttamente

Il client RDP di Microsoft è un esempio di un'applicazione client che non affronta con grazia problemi di routing IPv6. La maggior parte dei browser Web è in grado di gestire meglio i casi limite IPv6 come questo, quindi non tende a mostrare questo comportamento.

• Prova a utilizzare un client diverso. Forse sarai fortunato.

Mi rendo conto che non è molto utile per questa situazione, ma per gli implementatori che affrontano un dilemma simile, esiste una tecnica di implementazione nota come "Happy Eyeballs" (RFC 6555) che specifica una tecnica per connettersi simultaneamente a ipv4 e ipv6 e scegliere quale connette per primo.

Ecco la mia soluzione. Per impostazione predefinita, Windows assegna alle route IPv6 una priorità maggiore rispetto alle route IPv4. Se si modifica il criterio del prefisso IPv6, è possibile modificare questo comportamento per utilizzare IPv4 preferibilmente su IPv6.

Per essere sicuro che tutti i sistemi nella mia rete siano impostati allo stesso modo, ho messo i seguenti comandi in uno script .bat eseguito durante l'installazione del software dopo aver costruito o rinnovato una macchina.

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

Per spiegare cosa fa questo:

Le prime 3 linee disabilitano le interfacce di tunneling integrate, poiché sono ridondanti per la maggior parte delle reti. Potresti voler non usare quelle 3 linee se non stai fornendo i tuoi indirizzi IPv6 alle tue macchine, nel mio caso ho un server DHCPv6 e un'infrastruttura associata che assegna IPv6 per la connettività tunnel

Il secondo blocco di comandi elimina tutti i criteri prefisso di routing IPv6 esistenti.

Il terzo blocco ricrea quindi i criteri del prefisso IPv6, ma utilizza un diverso insieme di priorità. Allo stesso modo al prefisso corrispondente a IPv4 viene data la preferenza su IPv6 e la macchina vorrà quindi usare IPv4 a meno che l'applicazione non specifichi l'uso di IPv6.

Questa soluzione mantiene la funzionalità di doppio stack funzionale, ma la preferenza di utilizzare IPv4 significa che i siti con IPv6 incompleto, inaffidabile o con prestazioni scadenti eviteranno di utilizzarlo se non indicato da un programma sul sistema.

È mia opinione che fare in modo che i sistemi operativi utilizzino IPv6 rispetto a IPv4 stia effettivamente ostacolando l'adozione. Durante il periodo di transizione, ci saranno momenti in cui un host pensa di avere una connettività IPv6 ma in realtà non ha una connessione completamente funzionale, portando a malfunzionamenti del software e grandi ritardi. Molte persone che conosco hanno disabilitato IPv6 interamente sul proprio router come soluzione alternativa per gli ISP che distribuiscono IPv6 inizialmente in modo non funzionante prima di stabilire la piena connettività, e queste persone dimenticheranno semplicemente di abilitarlo lasciandole nuovamente senza IPv6 fino a quando non riconfigurano nuovamente il router.