¿Cuáles serían las desventajas/riesgos de usar AF_UNSPEC?

Question

De Beej's Guide to Network programming

Puede forzar que se use IPv4 o IPv6 en el campo ai_family, o dejarlo como AF_UNSPEC utilizar lo que sea. Esto es genial porque su código puede ser independiente de la versión de IP.

como dice el título - ¿cuáles serían las desventajas (o riesgos, si los hay) de utilizar siempre AF_UNSPEC, en lugar de especificar IPv4 o IPv6?

O solo por una razón: si se especifica la versión, ¿esto garantizará que esto y solo esta versión sea compatible?

---

Un poco de historia - Pienso acerca añadiendo soporte para IPv6 en cliente-servidor (C++) aplicaciones y ambas versiones deben ser apoyados. Así que me preguntaba si está bien usar AF_UNSPEC o es mejor "reconocer" la dirección de la cadena y usar AF_INET6 o AF_INET, dependiendo de la dirección.

Answer 1

Tiene que diferenciar entre aplicaciones de cliente y servidor.

En el cliente, es fácil: simplemente llame al getaddrinfo() y pruebe cada una de las respuestas en secuencia hasta que obtenga una conexión.

En el servidor, las cosas son un poco más difícil:

• hay sistemas cuyas pilas IPv4 y V6 están interconectados, no es suficiente con sólo escuchar en IPv6. Tal vez el socket debe estar habilitado para escuchar ambos.
• Otros sistemas, como Windows XP, tienen pilas separadas donde esta conexión no es posible. Allí tendrías que trabajar con varios enchufes a la vez. Déjame concentrarme en aquellos en lo siguiente.

Incluso en los servidores, getaddrinfo() se puede utilizar. Ahí usa la bandera AI_PASSIVE en las sugerencias. Entonces obtienes resultados. En todo esto, tendrás que escuchar, tal vez habilitar la bandera IPV6_V6ONLY.

accept() debe hacerse sin bloqueo o con select() o poll() (no estoy seguro si esto último es posible).

Answer 2

La forma en que las cosas deberían ser:

Las aplicaciones deben ser de capa 3 agnóstico. La conexión a otro sistema debe hacerse por nombre. El nombre debe resolverse en una o más direcciones, y la aplicación debe conectarse a ellas sin mirar el protocolo real que se está utilizando. De esta forma, la configuración de red es responsabilidad de los administradores de la red y del sistema. Si se introduce IPv6 en una red, la aplicación continúa funcionando sin siquiera notar la diferencia.

Algunos problemas del mundo real:

veces IPv6 está mal configurado, un firewall no sabe cómo tratar con IPv6, IPv6 sólo se utiliza en la red local sin necesidad de una conexión a internet, etc. no debería ser un problema, pero a veces te encuentras con una mala implementación o configuración. Para tratar con eso, el IETF está trabajando en un borrador llamado happy-eyeballs. Se asegura de que el usuario no advierta tales problemas. Eche un vistazo a ese borrador. El uso de las técnicas especificadas en ese borrador garantizará que su aplicación funcione bien para todos los usuarios.

Answer 3

Uno de los riesgos de usar AF_UNSPEC es que expone al cliente a respuestas más grandes de un servidor DNS malicioso que puede estar intentando utilizar CVE-2015-7547 para causar un desbordamiento de la pila de almacenamiento y causar la ejecución de código malicioso por el cliente De hecho, una solución propuesta para el defecto conocido en getaddrinfo es evitar el uso de AF_UNSPEC como se detalla en here en el informe de errores. El defecto de desbordamiento para las respuestas de DNS superiores a 2K afecta a glibc desde 2.9 y se repara en 2.23. Esto afecta a la mayoría de las distribuciones de Linux instaladas actualmente.