Con la evolución del protocolo IP de IPv4^[1] a IPv6^[2] surgieron varios cambios en la cabecera IP en cuanto a su longitud y a los campos que la conforman. Mientras que la longitud de la cabecera IPv4 es variable, la cabecera IPv6 tiene longitud fija. Unos campos permanecen con el mismo nombre y la misma funcionalidad mientras que otros fueron removidos y algunos fueron adicionados nuevos, como es el caso de la etiqueta de flujo. La IETF (Intenet Engineering Task Force), el grupo de trabajo de ingeniería de Internet quien es el organismo encargado de las normas y estandares de Internet, publicó varias RFCs (Request for Comments) dando orientaciones sobre la finalidad con la que fue creado el campo etiqueta de Flujo en la cabecera IPv6.

Inicialmente, en la RFC1707^[3] se expone la primera recomendación sobre la necesidad de un campo que conforme la cabecera IP para identificar paquetes pertenecientes a un flujo y que permitiese el envío salto por salto de los paquetes. Por tanto, a esta funcionalidad se le conoce como el antecesor de la etiqueta MPLS RFC3031^[4]. Luego la IETF publicó en la RFC1710^[5] una propuesta denominada SIPP (Simple Internet Protocol Plus), la cual incluyó el concepto de etiquetamiento de paquetes pertencientes a flujos de un tráfico específico. Finalmente, en la RFC1752^[6], se dio la especificación inicial del campo etiqueta de flujo dentro del diseño de IPv6.

En cuanto a la especificación del campo etiqueta de flujo inicio con una longitud de 28 bits en la RFC1710^[5], luego en la RFC1883^[7] se especificó a 24 bits y finalmente en la RFC2460[8] fue reducida a 20 bits. A partir de esta definición aparecieron varias incertidumbres acerca de su uso, tanto que, en la RFC2460^[8] este campo fue definido como experimental y sujeto a cambios.

Varios trabajos preliminares de la especificación del campo etiqueta de flujo fueron realizados por la IETF tales como en ^{[9], [10], [11], [12]}, hasta que se publicó una especificación más detallada en la RFC3697 ^[13]. Durante el tiempo que estuvo vigente la RFC3697 (aproximadamente 7 años), varias aproximaciones sobre metodologías para uso de la etiqueta de flujo fueron propuestas por investigadores para diferentes propósitos, tales como: conmutación de paquetes, soporte de calidad de servicio, filtrado de paquetes entre otros, pero estas soluciones vulneraban de alguna forma las recomendaciones de la RFC3697^[13]. Otro estudio de aproximaciones, recomendaciones e historia del campo etiqueta de flujo fue realizado en ^[14].

Por lo anterior, la IETF motivada por el poco uso práctico del campo etiqueta de flujo realiza un estudio de propuestas de casos de uso y publica la RFC6294^[15] donde proporciona los resultados de este estudio y el análisis de las incompatibilidades presentadas en las propuestas estudiadas con respecto a la especificación de la etiqueta de flujo RFC3697^[13]. Es así que, en la RFC6436 ^[16] recomienda la actualización de la RFC3697^[13]. Por tanto, es publicada la nueva especificación de la etiqueta de flujo mediante la RFC6437^[17], quedando como obsoleta la RFC3697^[13].

Por otro lado, aprovechando la similtud de las características del campo de la etiqueta de flujo con la etiqueta MPLS^[4], en ^[18] se propone una aproximación para conmutación rápida de paquetes y soportar ingeniería de tráfico en Internet usando la etiqueta de flujo. Finalmente, se puede concluir que actualmente este campo no ha sido muy explotado aún y sigue siendo un asunto abierto en investigación. La mayoría de las propuestas encontradas usan la etiqueta de flujo para soportar QoS, conmutación de paquetes, contribución a funciones de movilidad, balanceo de carga, filtrado de paquetes, seguridad e ingeniería de tráfico.