Resumen

  • RFC 7510 hace visible una entropía de flujo generada por el encapsulador en el puerto de origen UDP, para que equipos IP existentes distribuyan MPLS entre rutas ECMP o enlaces agregados.
  • Ni ese puerto ni el destino 6635 forman una credencial. Los pares del túnel, la configuración, los filtros, el dominio de congestión, las sumas de comprobación, las etiquetas MPLS y la protección de seguridad se controlan por separado.

El error empieza al llamar «sesión» al registro

Un colector de flujos recibe un quinteto: direcciones IP de origen y destino, dos puertos y un número de protocolo. La interfaz lo etiqueta como sesión UDP. El puerto de origen se mantiene constante durante una secuencia de paquetes, así que el nombre parece razonable.

En MPLS-in-UDP, esa lectura puede ser falsa. RFC 7510 dice que el puerto de origen sirve exclusivamente como fuente de entropía. El túnel es unidireccional y el tráfico no vuelve al número que ocupó ese campo. Un cortafuegos con estado puede necesitar reglas independientes para cada sentido.

El registro observado no deja de ser útil. Permite reconocer un paquete exterior y seguir el resultado de una decisión local de reparto. Lo que no permite es deducir que una aplicación escucha en ese puerto, que dos extremos mantienen una conversación o que el valor pertenece a un usuario estable.

La diferencia importa porque los sistemas administrativos tienden a heredar las etiquetas de los protocolos. Cuando «puerto» se convierte en «sesión», y «sesión» en «identidad», una ayuda de encaminamiento termina tomando decisiones para las que nunca fue diseñada.

Aprovechar el hardware que ya existe

La motivación de RFC 7510 es práctica. Muchos routers IP reparten microflujos TCP y UDP entre caminos de igual coste o miembros de una agregación de enlaces. Su hardware calcula un hash del quinteto y mantiene cada microflujo en una ruta mientras distribuye otros por alternativas disponibles.

El tráfico MPLS encapsulado de forma directa puede ofrecer poca variación a un dispositivo que no examina la pila interna de etiquetas. Varios flujos terminan en el mismo enlace aunque haya capacidad sin usar en otro. Exigir que cada equipo de tránsito comprenda el interior MPLS también elevaría el coste.

La solución añade IP y UDP por fuera. Las direcciones externas describen los extremos del túnel. El encabezado UDP ofrece campos que el router ya sabe incluir en el hash. El puerto de origen cambia entre flujos y proporciona la entropía necesaria para repartirlos.

El dibujo del formato conserva las fronteras. Primero aparecen «puerto de origen = entropía» y «puerto de destino = MPLS»; luego, longitud y suma UDP. Debajo están la pila de etiquetas MPLS y el cuerpo del mensaje. Es una envoltura de adaptación, no una sustitución de la semántica interna.

Una definición local dentro de 16 bits

El encapsulador genera un valor de 16 bits para identificar un flujo. Sin embargo, el documento deja fuera de alcance tanto la definición de flujo como el algoritmo. Cada implementación decide qué campos observar y cómo convertirlos en entropía.

Por eso el número carece de significado universal. Un equipo puede usar cabeceras internas; otro, información disponible antes en su canal de reenvío. Un analista que solo ve el puerto exterior no puede reconstruir de forma fiable un cliente, un servicio o un inquilino.

Cuando no hace falta entropía, los paquetes de un flujo deberían conservar una constante escogida al azar. No es una identidad persistente: es una medida para evitar que paquetes sucesivos caigan en caminos distintos y lleguen desordenados.

El RFC también propone trabajar en el intervalo 49152–65535. El encapsulador calcula un hash de 14 bits y fija los dos bits superiores a 11. Así se mantiene alejado de números bajos reservados para aplicaciones identificadas, sin perder demasiada variación.

Un espacio pequeño y local puede producir colisiones. Otro túnel puede reutilizar el mismo valor, y una actualización puede cambiar la función de hash. Vincular directamente ese puerto con facturación, titularidad o control de acceso convertiría una coincidencia técnica en una afirmación institucional.

El significado exacto del 6635

El puerto de destino es más estable. El registro de nombres de servicio y puertos de IANA asocia UDP 6635 con mpls-udp. Para un extremo ya preparado, indica que la carga útil debe interpretarse como un paquete MPLS.

IANA no certifica al emisor mediante ese registro. El número no prueba que la dirección de origen sea un par autorizado, que la pila de etiquetas sea válida en el contexto local ni que el tráfico deba admitirse. La convención coordina el análisis del formato, no la relación de confianza.

RFC 7510 exige que el encapsulador conozca previamente la capacidad de decapsulación del destino. Esa información puede proceder de configuración manual o de un anuncio dinámico, pero el mecanismo queda fuera del documento. El primer datagrama a 6635 no crea por sí solo una capacidad compartida.

La regla de acceso correcta comienza por el par configurado: direcciones esperadas, interfaz, dominio, estado de señalización y protección necesaria. Solo dentro de ese vínculo el puerto registrado decide qué analizador debe recibir la carga.

La pila de etiquetas no desaparece

Al retirar UDP, el receptor encuentra una pila MPLS. RFC 3032 define su codificación. RFC 3031, de Eric Rosen, Arun Viswanathan y Ross Callon, define la etiqueta como un identificador corto, fijo y de significado local para el reenvío.

Ese carácter local impide otra extrapolación. El puerto 6635 tiene alcance mundial; las etiquetas internas no. El decapsulador debe entrar en el espacio de etiquetas correcto y aplicar las reglas de asignación pertinentes. Una etiqueta fuera de contexto no adquiere autoridad porque viajara bajo un número registrado.

Existe además entropía dentro de MPLS. RFC 6790 define un indicador y una etiqueta de entropía en la propia pila. RFC 7510 sitúa la señal en el puerto exterior para hacerla visible a routers IP que quizá no lean las etiquetas.

Son mecanismos de capas distintas y pueden servir a equipos distintos. Ninguno autentica. La etiqueta interna no representa a un usuario, y el puerto exterior no representa una sesión. La posición decide quién puede usar la señal; no decide quién tiene derecho a enviar.

La prueba que aporta un dispositivo con estado

La asimetría del túnel contradice una suposición común de NAT y cortafuegos: que una respuesta intercambiará la misma pareja de puertos. El RFC advierte que el tráfico bidireccional puede requerir una configuración separada por sentido.

Ese detalle es una guía para la telemetría. El quinteto exterior puede agrupar paquetes que siguen una decisión de hash. La base de configuración identifica el par permitido. La pila de etiquetas establece el contexto de reenvío. Los campos interiores, si son observables, describen la comunicación transportada.

Relacionar esos datos mejora una investigación. Fundirlos en una sola «sesión» borra sus distintos niveles de certeza. Incluso una secuencia larga con un puerto estable no demuestra que exista una respuesta asociada ni que el emisor tenga permiso.

La disciplina consiste en conservar la procedencia de cada afirmación. Un valor visto en el paquete es evidencia de que ese valor fue enviado. La autorización procede de otro registro; la identidad, de otra verificación.

Rendimiento, suma de comprobación y riesgo

Para IPv4, RFC 7510 recomienda una suma de comprobación UDP igual a cero por razones de rendimiento o implementación, aunque advierte que proteger etiquetas puede ser importante para determinadas VPN. En IPv6 la suma debe usarse por defecto.

RFC 6935 permite una excepción limitada de suma cero en túneles IPv6. RFC 6936 fija condiciones exigentes: entorno muy controlado, riesgo de corrupción comprendido, aplicaciones tolerantes y aceptación operativa de las consecuencias. Un equipo que descarte esos datagramas puede crear un agujero negro.

RFC 8085 incorpora después la entropía de puerto a una guía UDP más amplia. El mensaje operativo es que no se pueden tomar únicamente los campos convenientes para ECMP. También deben asumirse la congestión, las sumas y el comportamiento de dispositivos intermedios.

Eliminar una comprobación puede ahorrar trabajo, pero transfiere la exposición a daños no detectados. La entropía no paga esa deuda. Un paquete corrupto no se vuelve correcto por haber sido distribuido con eficiencia.

El perímetro de cooperación

RFC 7510 restringe MPLS-in-UDP a la red de un operador o a redes adyacentes de operadores que cooperan y gestionan el tráfico para evitar congestión. No lo prescribe para el Internet abierto, donde se necesita control de congestión. También recomienda filtros que impidan la fuga de paquetes por error o mala configuración.

La restricción marca dónde pueden alinearse incentivos y responsabilidades. Dentro de un dominio controlado, las partes coordinan capacidad, admisión, vigilancia y respuesta. Fuera de él, un túnel UDP puede imponer su congestión a redes que no aceptaron la carga.

La seguridad mantiene el mismo límite. MPLS-in-UDP no garantiza por sí mismo integridad o privacidad y no autentica al encapsulador. El RFC considera IPsec y DTLS cuando hacen falta. IANA reserva 6636 para MPLS-in-UDP con DTLS, pero las claves, los pares y la política siguen necesitando una relación previa.

El límite de confianza incluye direcciones de extremos, configuración o señalización, dominio permitido, filtros, gestión de congestión, política de suma, espacio de etiquetas y cualquier mecanismo de autenticación. El 6635 funciona dentro de ese límite; no lo constituye.

Ross Callon dentro del registro compartido

El perfil de Ross Callon en IETF Datatracker enumera ocho RFC, entre ellos RFC 3031 y RFC 7510. La trayectoria documental abarca asignación de direcciones OSI, transición IPv6, MPLS y VPN de proveedor.

El dato establece coautoría, no propiedad individual del estándar. RFC 7510 tiene cinco autores y es un documento de consenso del IETF. Implementadores, operadores, IANA y comunidades técnicas toman decisiones diferentes. Un perfil de persona debe hacer visibles esas dependencias.

Sí aparece una continuidad útil: RFC 3031 acota el significado local de las etiquetas; RFC 7510 coloca esa pila en una envoltura que equipos IP existentes pueden repartir. Ambos trabajos funcionan cuando los campos conservan un mandato limitado.

Un puerto de origen puede ser entropía. Un puerto registrado puede identificar una carga. Una etiqueta puede seleccionar reenvío local. La interoperabilidad no exige que alguno de ellos se convierta en identidad, propiedad o permiso.

Límites de la evidencia

Las fuentes demuestran el formato y las restricciones de RFC 7510, sus recomendaciones de suma y seguridad, los registros de IANA, los estándares de etiquetas y la coautoría documentada de Ross Callon. No prueban el volumen actual de despliegue, el algoritmo de un proveedor, un incidente real causado por colisión ni un cargo institucional actual de Callon.

La advertencia contra usar entropía como identidad es un análisis editorial derivado de la semántica expresa y de los límites de seguridad. No relata una intrusión identificada. Tampoco sostiene que la entropía UDP exterior y las etiquetas de entropía MPLS sean intercambiables.

Fuentes