Resumen

  • Una llamada correcta a IPV6_ADDR_PREFERENCES confirma que la aplicación expresó una preferencia coherente; no confirma que existiera o se eligiera una dirección con ese atributo.
  • Cuando el atributo es obligatorio, RFC 5014 exige seleccionar, releer y validar antes de continuar; la transmisión, la ruta y el éxito siguen siendo hechos posteriores.

El manual operativo dice «usar origen temporal». El host sólo tiene candidatos públicos, acepta la opción y mantiene la comunicación. El servicio funciona; el informe de privacidad, en cambio, describe una fuente que nunca existió.

Ése es el problema que RFC 5014 permite ver. El documento no sustituye el algoritmo de selección de IPv6. Añade una forma para que la aplicación invierta determinadas preferencias y deje a la pila decidir todo lo demás. La unidad de control es cada socket mediante IPV6_ADDR_PREFERENCES, acompañada por indicadores equivalentes en getaddrinfo().

Las opciones forman tres pares: domicilio o care-of, temporal o pública, CGA o no-CGA. Se pueden combinar atributos de pares diferentes. Pedir a la vez ambos extremos del mismo par es contradictorio y falla. Esa comprobación protege la coherencia sintáctica de la política, no su cumplimiento material.

El RFC eligió preferencias en lugar de requisitos. Si no hay una dirección temporal, una pública puede ganar. Si una combinación solicita domicilio y temporal pero sólo existen direcciones públicas de domicilio, la parte disponible dirige la selección y la política predeterminada cubre la otra. Una capacidad no implementada debe ignorarse silenciosamente. El retorno exitoso de la API no informa de cuál de esos caminos ocurrió.

Además, el orden de destinos puede cambiar según la fuente prevista. Por eso la aplicación debe usar valores semánticamente iguales al consultar getaddrinfo() y al configurar el socket. Si no lo hace, el comportamiento queda indefinido. Registrar sólo setsockopt() borra la decisión anterior que pudo colocar un destino por delante de otro.

También existe una jerarquía interna. Una dirección fijada por bind() o IPV6_PKTINFO prevalece sobre la preferencia. El sistema puede mostrar que el indicador sigue activo mientras otra orden determina efectivamente la fuente. La configuración y la autoridad no son el mismo registro.

RFC 5014 reserva un procedimiento para la aplicación que debe fallar antes que usar el atributo equivocado. Primero expresa los mismos indicadores en resolución y socket. Después pide a la pila seleccionar una fuente. Luego obtiene la elegida mediante getsockname() y consulta sus atributos con inet6_is_srcaddr(). Si la respuesta no satisface todos los requisitos, cierra o aborta.

El momento de seleccionar importa. connect() sobre TCP puede enviar un SYN antes de que la aplicación inspeccione la fuente. Para impedir incluso ese paquete, el RFC define bind2addrsel(), que enlaza la dirección que habría sido escogida para un destino sin iniciar la conexión. En UDP, connect() realiza la selección local sin enviar por sí mismo. Una auditoría debe saber qué llamada se usó y si la validación precedió realmente a la salida.

La función de comprobación devuelve 1, 0 o -1. El 1 significa que la dirección es local y satisface todos los indicadores válidos; el 0, que no coincide; el -1, que no pertenece al nodo o que la entrada no es válida. Ninguno de esos valores certifica el camino remoto. Incluso el atributo de domicilio puede resultar verdadero si no hay Mobile IPv6 o si el nodo está en casa.

Tampoco conviene convertir nombres técnicos en promesas comerciales. RFC 8981 limita la ventana de correlación trivial al cambiar direcciones temporales; otras capas pueden seguir vinculando actividad. RFC 3972 permite verificar la asociación entre una CGA y material de clave, pero la CGA no es una identidad certificada. Solicitarla no demuestra que se eligió, que se verificó una firma o que el interlocutor quedó autorizado.

La evolución de las normas añade otra cautela. RFC 5014 tomó como base RFC 3484 y su preferencia pública de la época. RFC 6724 sustituyó ese documento y pasó a preferir temporales en la regla correspondiente. El control debe capturar la política y el conjunto de candidatos reales, no suponerlos desde una norma antigua.

Un recibo útil contiene la aplicación y el socket, los indicadores solicitados y el valor previo, la consulta del resolvedor y su orden de destinos, capacidades ignoradas, candidatos disponibles, revisión de política, cualquier fuente explícita, método de selección, posibilidad de envío temprano, lectura de getsockname(), resultado de inet6_is_srcaddr(), decisión de continuar o parar y, en campos separados, paquete saliente, retorno y resultado de aplicación.

No es una ampliación secreta de RFC 5014. Es la disciplina de capas de realidad de Heng Lu aplicada a una interfaz: la intención pertenece al programa, la elección a la pila, la propiedad a la validación local, la conectividad a la red y el resultado al servicio. Una fila de cumplimiento que fusiona esas capas ahorra espacio y pierde verdad.

Fuentes