Quali sono gli svantaggi dell'abilitazione di IPv6 nei servizi rivolti al pubblico?

La nostra rete interna e i servizi interni sono abilitati per IPv6 e stiamo valutando di abilitare IPv6 su server SMTP, DNS e Web rivolti al pubblico. Tutte le guide / white paper che ho letto sull'argomento parlano solo dei vantaggi, ma sono sicuro che ci sono anche alcuni aspetti negativi. Per esempio:

1. I clienti con IPv6 tramite tunnel avranno un accesso più lento ai nostri servizi se abilitiamo IPv6.
2. I client con IPv6 non funzionante non potranno accedervi affatto.

Dato che solo una percentuale molto piccola di utenti ha un IPv6 funzionante e quelli che lo fanno sono di solito dual-stack, sono propenso a pensare che abilitare IPv6 quando non si controlla entrambi i lati del canale di comunicazione sia in realtà una cattiva idea nel 2011 .

Ci sono ricerche / documenti / articoli su questo argomento?

Questo articolo è una panoramica di un esperimento di vita reale. Sostengono di avere solo problemi minori.

Forse potrebbe aiutare un po ' a configurare i server DNS per inviare risposte IPv6 solo su interfacce IPv6 - escluderà gli ISP che non hanno affatto IPv6. Non tutti i client utilizzano i resolver DNS forniti dal proprio ISP, ma molti lo fanno. Inoltre, l' ISP con IPv6 non significa che i suoi clienti abbiano IPv6. Eppure è un miglioramento.

A proposito, se qualcuno è abbastanza intelligente da installare il tunnel, probabilmente sa cosa fa e dovrebbe incolpare nessuno se non se stesso. :)

Modificare:

Manuale BIND9:

filter-aaaa-on-v4 Questa opzione è disponibile solo quando BIND 9 è compilato con l'opzione --enable-filter- aaaa nella riga di comando "configura". Ha lo scopo di aiutare il passaggio da IPv4 a IPv6 non fornendo indirizzi IPv6 ai client DNS a meno che non abbiano connessioni a Internet IPv6. Questo non è raccomandato se non assolutamente necessario.

... Questo meccanismo si applica ai record autorevoli e non autorevoli. ...

Il giorno del World IPv6 all'inizio di quest'anno è stato un test di questo. I risultati furono misti , ma finirono meglio di quanto temuto . Il timore era la rottura di massa poiché i client abilitati per IPv6 nelle isole v6 non potevano accedere ai siti v6, ma alla fine ciò non avveniva più spesso di quanto teorizzato.

Un grande asporto è che i browser moderni gestiscono la jiggery-pokery v4 / v6 in un modo che non stacca gli utenti quasi quanto due anni fa.

In pratica, uno dei maggiori successi per andare su v6 è che alcuni client v6 che hanno tunnel v6 anziché connessioni native v6 a Internet potrebbero finire per avere il loro traffico prendere un percorso più lungo / lento verso il tuo sito di quanto farebbero su v4 nativo. Funzionerà ancora, caricherà più lentamente.

I risultati della giornata mondiale dell'IPv6 hanno dimostrato che questo non è un grosso problema. Qualcuno con un tunnel IPv6 ha scelto consapevolmente per quel tunnel, quindi se il tunnel è molto più lento di IPv4, questo è per scelta dell'utente / amministratore di sistema. I browser attuali (Firefox, Chrome, Safari e persino IE nel prossimo futuro) useranno un sistema chiamato Happy Eyeballs o qualcosa del genere. Descrizione molto approssimativa di questo: quando si apre una connessione IPv6 c'è un breve set di timer (penso che Chrome usi 300ms). Se il timer scade prima che venga stabilita la connessione IPv6, tenterà di impostare una connessione IPv4. L'utente non noterà alcun potenziale problema con IPv6.