Resumen

  • El Flow Label ocupa veinte bits de la cabecera fija de IPv6 y puede combinarse con las direcciones de origen y destino para formar una clave de tres campos.
  • La etiqueta debe ser estable dentro de un flujo y estar bien distribuida entre flujos, pero puede colisionar y no está protegida contra cambios o falsificación.
  • Las RFC 6438 y 7098 muestran usos acotados en túneles, ECMP/LAG y balanceadores de capa 3/4 a partir del modelo revisado por la RFC 6437.

Lo que está disponible antes que los puertos

La posición fija es la ventaja mecánica. Muchos sistemas reparten tráfico mediante un hash de direcciones y puertos. En IPv6, localizar los puertos puede exigir recorrer cabeceras de extensión; en ciertos fragmentos no aparecen, y el cifrado puede impedir su lectura. El Flow Label no recupera esa información. Ofrece una entrada distinta, inmediatamente visible, para que el equipo no tenga que fingir que conoce el transporte.

Su valor cero indica un paquete sin etiquetar. Para una etiqueta no nula, una clasificación posible combina Flow Label, dirección de origen y dirección de destino. El resultado no es una identidad. Un «flujo» de IPv6 tampoco tiene que coincidir exactamente con una conexión de transporte, aunque la RFC 6437 aconseja que conexiones o corrientes de aplicación sin relación reciban normalmente flujos distintos.

La fuente debería asignar el mismo valor no nulo a todos los paquetes de un flujo. Al mirar muchos flujos, los valores deberían acercarse a una distribución uniforme y resultar difíciles de predecir. Un hash de veinte bits del quíntuplo o una asignación pseudoaleatoria con un estado mínimo son ejemplos permitidos, no recetas obligatorias. La asignación secuencial se desaconseja.

El espacio finito admite colisiones. Si dos flujos simultáneos con las mismas direcciones reciben el mismo label, un equipo que se base en él los tratará igual. La especificación no promete distinguirlos siempre. Busca afinidad y reparto útiles, no un nombre único para cada conversación.

Un túnel con demasiada igualdad exterior

La RFC 6438 parte de un problema concreto. En un túnel IP sobre IPv6, numerosos flujos internos pueden compartir las dos direcciones de la cabecera exterior. Si ECMP o una agregación de enlaces solo ve esas direcciones, el tráfico puede polarizarse en un miembro del conjunto.

El extremo emisor del túnel puede derivar la etiqueta exterior de un par o quíntuplo interno, conservarla durante ese flujo y generar otros valores para otros flujos. Así aporta variedad al hash sin pedir a los routers intermedios que interpreten las sesiones internas. Una colisión ocasional sigue siendo aceptable: dos flujos de usuarios compartirán el tratamiento basado en la etiqueta, no una identidad ni un derecho.

En las granjas de servidores, la RFC 7098 propone otro uso. Un balanceador de capa 3/4 puede tomar dirección de origen y label, o destino, origen y label, como clave de sesión. En el modo sin estado, un hash hace que los paquetes del flujo vuelvan al mismo servidor. En el modo con estado, se guarda la relación entre clave y servidor. Si el label es cero, se mantiene el camino tradicional que inspecciona el transporte.

Ese estado tampoco resuelve todas las fronteras. Si una nueva sesión, con las mismas direcciones, reutiliza una etiqueta, la clave por sí sola no permite distinguirla de la anterior. La persistencia del tratamiento no equivale a comprender el ciclo de vida de la aplicación.

Una revisión que redujo la semántica

La RFC 6437 sustituyó el planteamiento anterior de la RFC 3697. Favoreció etiquetas no nulas, valores uniformemente distribuidos y un modelo de asignación sin estado. Conservó la expectativa de que una etiqueta no nula llegue sin cambios. Un equipo de tránsito puede etiquetar paquetes con valor cero por cuenta de la fuente, pero esa función debe ser configurable y estar desactivada de forma predeterminada; se prefiere la fuente.

La interpretación histórica es paradójica solo en apariencia: el campo se volvió más aprovechable cuando dejó de exigir un significado rico. Sirvió como material de clasificación, no como lenguaje de la aplicación. Esta lectura se deriva de la mecánica de las RFC; no demuestra que todas las redes la hayan adoptado.

Las fuentes tampoco ofrecen un censo actual, comparaciones de fabricantes ni mediciones de rendimiento. No permiten afirmar cuántas etiquetas son hoy distintas de cero o qué ganancia consigue un despliegue particular.

Fuentes