Gestiamo un servizio sociale / locale che beneficia della geolocalizzazione dell'IP degli utenti. Il problema è che con IPv6 la geolocalizzazione è un po 'più spessa che con IPv4.
C'è un modo per preferire le connessioni in entrata su IPv6, su un host Ubuntu con nginx? La configurazione è simile alla seguente:
server {
listen 80 default_server;
listen [::]:80 ipv6only=off default_server;
}
Risposte:
La preferenza IPv6 / IPv4 è determinata dall'iniziatore di una connessione, ovvero dal browser web. Le regole di selezione dell'indirizzo sono definite in RFC 6724 . Mentre questi possono essere sovrascritti, è solo l'utente a riconfigurare il proprio sistema operativo.
L'unico modo per forzare qualcuno a utilizzare IPv4 è di non offrire affatto IPv6. Ovviamente questa non è una soluzione pratica anche a medio termine ...
Quindi, torniamo al problema originale: la geolocalizzazione per IPv6 è "un po 'più spessa che con IPv4".
In parte questo dipende molto da dove ottieni i tuoi dati di geolocalizzazione. Maxmind, ad esempio, fornisce il mio indirizzo IPv6 solo come "Stati Uniti", senza città e con un interessante insieme di coordinate , mentre Google identifica almeno correttamente l'area metropolitana a cui si trovano ancora a circa 50 miglia di distanza. Sia Maxmind che Google consentono correzioni di segnalazione e almeno per Maxmind chiunque può farlo per qualsiasi indirizzo IP.
Non mi aspetto che questa situazione duri molto a lungo. Man mano che l'utilizzo di IPv6 continua ad espandersi, gli utenti di tali servizi di geolocalizzazione richiederanno una maggiore precisione per gli indirizzi IPv6 e dovranno consegnarlo alla fine, almeno per i clienti paganti, per timore che quei clienti vadano altrove.
Nel frattempo, dovresti essere sicuro che la tua applicazione abbia altri modi per localizzare gli utenti. Se hanno effettuato l'accesso, è possibile leggere il loro account esistente per indizi sulla loro posizione. Potresti chiedere all'utente di selezionare esplicitamente un Paese. E così via...
Un'altra cosa che puoi fare è fornire un sottodominio solo IPv4 e un sottodominio solo IPv6 del tuo sito web, ognuno dei quali tenta di caricare le tue pagine. È quindi possibile correlarli dal lato client e riportarli al server. Non a caso Maxmind lo sta già facendo sul proprio sito web.
Tali preferenze possono essere espresse utilizzando i record SRV. Purtroppo quelli non sono supportati per HTTP. Quindi ti rimane una situazione in cui solo il client sta facendo la scelta tra IPv4 e IPv6.
Molti client utilizzano il tempo di andata e ritorno di SYN + SYN-ACK per decidere quale dei due utilizzare. Quindi, rallentando l'invio di un pacchetto SYN-ACK su IPv6, puoi fare in modo che la maggior parte dei client preferisca IPv4. Ma rallentare deliberatamente il tuo sito è un approccio terribile.
Invece farei un passo indietro e guarderei il problema. Desideri dati di geolocalizzazione migliori. Ogni volta che un visitatore accede al tuo sito, conosci immediatamente uno dei loro indirizzi IP. Se questo sarà un indirizzo IPv4 o IPv6 dipende da quale browser preferisce comunicare con il tuo server.
All'interno della tua pagina puoi utilizzare una richiesta AJAX per conoscere un altro indirizzo IP. Per i client che utilizzano IPv4, inviare la richiesta AJAX a un dominio solo IPv6, per i client che utilizzano IPv6, inviare la richiesta AJAX a un dominio solo IPv4.
Non appena la richiesta AJAX arriva sul server, si conoscono gli indirizzi IPv4 e IPv6 dell'utente. Conoscere questa corrispondenza ti consentirà di fare la geolocalizzazione meglio di quanto potresti fare conoscendo solo una delle due.
Vedrai spesso casi in cui la richiesta AJAX non arriva mai sul server. Per quegli utenti dovrai fare la geolocalizzazione come puoi fare meglio in base a un solo indirizzo IP. Ma finché la risposta a quella richiesta AJAX non viene utilizzata per nulla sul lato client, l'utente non noterà nemmeno quelle richieste AJAX non riuscite. Quindi nessun rallentamento percepito o comportamento irregolare sarà causato dalle richieste AJAX.