Resumen

  • RFC 3542 separó las opciones IPv6 persistentes del socket de los datos auxiliares asociados a un mensaje. Un dato auxiliar sustituye solo la opción persistente del mismo nombre; las demás siguen activas.
  • El alcance tiene límites concretos: un dato de longitud cero puede desactivar una opción para un datagrama, los paquetes ya en cola pueden carecer de metadatos recién solicitados y las llamadas de envío TCP no equivalen a segmentos transmitidos individuales.

Imaginemos un socket UDP de larga duración que una aplicación de diagnóstico usa para enviar tráfico. El programa ha elegido una interfaz de salida y varias opciones IPv6 que deben aplicarse a cada datagrama. Un mensaje excepcional necesita otra ruta. Si la implementación trata el dato de ese mensaje como sustituto de todo el conjunto de valores predeterminados, el paquete quizá tome la ruta solicitada, pero también perderá decisiones que nadie pidió cambiar.

RFC 3542, publicado en mayo de 2003 como Advanced Sockets Application Program Interface (API) for IPv6, hizo explícito ese límite. El documento es Informational: no define un protocolo en la red. Describe la frontera entre la aplicación y el núcleo del sistema, es decir, cómo un programa puede pedir información o procesamiento IPv6. Una petición aceptada no demuestra por sí sola qué paquete salió ni qué ocurrió después.

La diferencia con su antecesor, RFC 2292, explica la regla. La interfaz antigua trataba varias opciones persistentes como un conjunto; la información auxiliar de un mensaje podía sustituir ese conjunto. RFC 3542 amplió y separó los controles para que cada opción persistente y cada dato auxiliar tuvieran identidad propia. Al volverse individual el estado, también debía ser individual el alcance de la sustitución: solo se reemplazaba la opción del mismo tipo.

No es un detalle de estilo. Es una definición de cuánto puede cambiar una excepción. Si el socket conserva elecciones para la interfaz, la clase de tráfico y los encabezados de extensión, un dato de mensaje dirigido al enrutamiento no concede permiso para borrar las otras dos. El núcleo combina el estado persistente con la excepción limitada al construir el datagrama; esa combinación todavía es distinta de observar el paquete real.

La regla permite expresar también una ausencia precisa. Una aplicación puede configurar IPV6_HOPOPTS como opción persistente y enviar, para un mensaje, un dato auxiliar del mismo tipo y longitud cero. Así omite el encabezado Hop-by-Hop en ese datagrama. El cero no significa «olvidar todos los valores predeterminados»: desactiva una opción identificada, durante un único envío. El datagrama siguiente vuelve a heredar el valor persistente, salvo que la aplicación lo cambie aparte.

La recepción introduce una cuestión temporal. La aplicación activa opciones IPV6_RECVxxx y recvmsg() puede devolver información disponible como objetos auxiliares. Si no aparece el objeto esperado, tal vez el paquete no tuviera la característica. Pero RFC 3542 advierte que un paquete que ya estaba en cola cuando se activó la opción de recepción puede no incluir los nuevos metadatos. Por tanto, la ausencia puede describir el paquete o el momento en que empezó la observación; no permite afirmar, sin más evidencia, qué había en el cable.

TCP rompe la analogía con los datagramas independientes. RFC 3542 no define el mismo control auxiliar por envío para TCP porque una llamada de la aplicación no corresponde a un segmento único en la red. Una retransmisión puede utilizar información persistente antigua o nueva; el estándar no promete un límite por mensaje que TCP no puede conservar. También deja indefinida cierta información opcional de recepción para TCP y advierte que no debe usarse para decisiones de control de acceso.

Los ejemplos históricos también necesitan contexto. RFC 3542 incluye un encabezado de enrutamiento Type 0 heredado de la época de RFC 2460. RFC 8200 es la especificación base actual de IPv6. El ejemplo antiguo documenta las funciones disponibles entonces; no es una recomendación vigente para enrutar tráfico.

La historia de RFC 3542 es, en definitiva, una excepción mejor acotada: el reemplazo de todo el conjunto de RFC 2292 se convirtió en la sustitución de la opción homónima. Para demostrar el resultado hay que registrar por separado el estado del socket antes de la llamada, el dato auxiliar del mensaje, el paquete que se observó y el resultado posterior. Que sendmsg() acepte una solicitud es evidencia de intención registrada por la interfaz, no prueba de que el paquete haya seguido la ruta prevista.

Fuentes