Cómo soportar las conexiones IPv4 e IPv6

Question

Actualmente estoy trabajando en una aplicación de socket UDP y necesito crear soporte para que las conexiones IPV4 e IPV6 puedan enviar paquetes a un servidor.

Esperaba que alguien me ayudara y me indicara la dirección correcta; La mayoría de la documentación que encontré no estaba completa. También sería útil si pudiera señalar alguna diferencia entre los sockets Winsock y BSD.

Gracias de antemano!

Answer 1

El mejor enfoque es crear un socket de servidor IPv6 que también pueda aceptar conexiones IPv4. Para hacerlo, cree un socket IPv6 normal, desactiva off la opción de socket IPV6_V6ONLY , vincúlala a " cualquier " Dirección, y empezar a recibir. Las direcciones IPv4 se presentarán como direcciones IPv6, en el formato IPv4-mapped .

La principal diferencia entre los sistemas es si IPV6_V6ONLY está a) disponible, yb) activado o desactivado de forma predeterminada. Está desactivado de forma predeterminada en Linux (es decir, permite sockets de pila doble sin setsockopt), y está activado en la mayoría de los otros sistemas.

Además, la pila de IPv6 en Windows XP no admite esa opción. En estos casos, deberá crear dos sockets de servidor separados y colocarlos en seleccionar o en varios subprocesos.

Answer 2

La API de socket se rige por los RFC de IETF y debe ser la misma en todas las plataformas, incluidas las ventanas WRT IPv6.

Para aplicaciones IPv4 / IPv6, es TODOS acerca de getaddrinfo () y getnameinfo () . getaddrinfo es un genio: busca en DNS, nombres de puertos y capacidades del cliente para resolver la eterna pregunta de "¿Puedo usar IPv4, IPv6 o ambos para llegar a un destino en particular?". va a la ruta de doble pila y desea que devuelva las direcciones IPv6 asignadas a IPv4, también lo hará.

Proporciona una estructura directa sockaddr * que se puede conectar a bind () , recvfrom () , sendto () y la familia de direcciones para socket () ... En muchos casos, esto significa que no hay estructuras sockaddr_in (6) desordenadas para completar y tratar.

Para las implementaciones de UDP, debería tener cuidado al establecer sockets de pila doble o, más generalmente, vincular a todas las interfaces ( INADDR_ANY ). El problema clásico es que, cuando las direcciones no están bloqueadas (ver bind () ) a interfaces específicas y el sistema tiene múltiples solicitudes de interfaces, las respuestas pueden transitar desde diferentes direcciones para computadoras con múltiples direcciones basadas en el los caprichos de la tabla de enrutamiento del sistema operativo, los protocolos de aplicación confusos, especialmente los sistemas con requisitos de autenticación.

Para implementaciones UDP donde esto no sea un problema, o TCP, los sockets de pila dual pueden ahorrar mucho tiempo cuando IPv * habilita su sistema. Se debe tener cuidado de no confiar completamente en la pila dual, donde no es absolutamente necesario, ya que no hay escasez de plataformas razonables (Old Linux, BSD, Windows 2003) implementadas con pilas de IPv6 que no sean capaces de sockets de pila doble.

Answer 3

He estado jugando con esto en Windows y en realidad parece ser un problema de seguridad allí, si se vincula a la dirección de bucle de retorno, el socket de IPv6 está correctamente enlazado a [:: 1] pero el socket IPv4 asignado es vinculado a INADDR_ANY, por lo que su aplicación (supuestamente) local y segura está realmente expuesta al mundo.

Answer 4

Las RFC no especifican realmente la existencia de la opción de socket IPV6_V6ONLY, pero, si está ausente, las RFC son bastante claras de que la implementación debe ser como si esa opción fuera FALSA.

Cuando la opción está presente, yo argumentaría que debería ser FALSO por defecto, pero, por razones de comprensión, las implementaciones de BSD y Windows se ponen por defecto en VERDADERO. Existe una extraña afirmación de que esto es un problema de seguridad porque un programador desconocido de IPv6 podría vincularse pensando que estaban vinculando solo a IN6ADDR_ANY por solo IPv6 y accidentalmente acepta una conexión IPv4 que causa un problema de seguridad. Creo que esto es tanto absurdo como absurdo, además de una sorpresa para cualquiera que espere una implementación compatible con RFC.

En el caso de Windows, la falta de compatibilidad generalmente no será una sorpresa. En el caso de BSD, esto es desafortunado en el mejor de los casos.