Tenemos un servicio social / local que se beneficia de la geolocalización de la IP de los usuarios. El problema es que con IPv6, la geolocalización es bastante más complicada que con IPv4.
¿Hay alguna manera de preferir las conexiones entrantes sobre IPv6, en un host Ubuntu con nginx? La configuración se ve así:
server {
listen 80 default_server;
listen [::]:80 ipv6only=off default_server;
}
Respuestas:
La preferencia IPv6 / IPv4 está determinada por el iniciador de una conexión, es decir, el navegador web. Las reglas de selección de dirección se definen en RFC 6724 . Si bien estos pueden ser anulados, solo es por el usuario que reconfigura su sistema operativo.
La única forma en que puede obligar a alguien a usar IPv4 es no ofrecer IPv6 en absoluto. Obviamente, esta no es una solución práctica, incluso a medio plazo ...
Entonces, volvamos al problema original: la geolocalización para IPv6 es "un poco más asquerosa que con IPv4".
En parte, esto depende mucho de dónde obtenga sus datos de geolocalización. Maxmind, por ejemplo, solo da mi dirección IPv6 como "Estados Unidos" sin ninguna ciudad y un conjunto interesante de coordenadas , mientras que Google al menos identifica correctamente el área metropolitana a la que todavía están a 50 millas de distancia. Tanto Maxmind como Google permiten correcciones de informes, y al menos para Maxmind cualquiera puede hacer esto para cualquier dirección IP.
No esperaría que esta situación dure mucho tiempo. A medida que el uso de IPv6 continúa expandiéndose, los usuarios de dichos servicios de geolocalización exigirán una mayor precisión para las direcciones IPv6, y eventualmente tendrán que entregarla, al menos para los clientes que pagan, para que esos clientes no vayan a otro lado.
Mientras tanto, debe asegurarse de que su aplicación tenga otras formas de localizar usuarios. Si iniciaron sesión, puede leer su cuenta existente para obtener pistas sobre su ubicación. Puede pedirle al usuario que seleccione explícitamente un país. Y así...
Otra cosa que puede hacer es proporcionar un subdominio solo IPv4 y un subdominio solo IPv6 de su sitio web, cada una de las cuales sus páginas intentan cargar. Luego puede correlacionarlos del lado del cliente e informar al servidor. No es coincidencia que Maxmind ya esté haciendo esto en su propio sitio web.
Dichas preferencias pueden expresarse utilizando registros SRV. Lamentablemente, esos no son compatibles con HTTP. Entonces, queda una situación en la que el cliente solo está eligiendo entre IPv4 e IPv6.
Muchos clientes usan el tiempo de ida y vuelta de SYN + SYN-ACK para decidir cuál de los dos usar. Entonces, al ralentizar el envío de un paquete SYN-ACK en IPv6, puede hacer que la mayoría de los clientes prefieran IPv4. Pero deliberadamente ralentizar su sitio es un enfoque terrible.
En cambio, daría un paso atrás y miraría el problema. Desea mejores datos de geolocalización. Cada vez que un visitante accede a su sitio, inmediatamente conoce una de sus direcciones IP. Si será una dirección IPv4 o IPv6 depende de cuál sea su navegador preferido para comunicarse con su servidor.
Dentro de su página puede hacer uso de una solicitud AJAX para conocer otra dirección IP. Para los clientes que usan IPv4, envíe la solicitud AJAX a un dominio solo IPv6, para los clientes que usan IPv6 envíe la solicitud AJAX a un dominio solo IPv4.
Tan pronto como la solicitud AJAX llegue al servidor, conocerá las direcciones IPv4 e IPv6 del usuario. Conocer esta correspondencia le permitirá realizar la geolocalización mejor de lo que podría hacerlo conociendo solo uno de los dos.
A menudo verá casos en los que la solicitud AJAX nunca llega al servidor. Para esos usuarios, tendrá que hacer la geolocalización como mejor puede hacerlo basándose en una sola dirección IP. Pero mientras la respuesta a esa solicitud de AJAX no se utilice para nada del lado del cliente, el usuario ni siquiera notará las solicitudes de AJAX que fallan. Por lo tanto, las solicitudes AJAX no causarán una desaceleración percibida o un comportamiento errático.