Resumen

  • En PPP, el campo de protocolo es siempre 0x0281 cuando la trama lleva MPLS. La dirección de asignación de la etiqueta superior procede de un contrato separado para esa dirección punto a punto; si falta, no debe deducirse del número.
  • RFC 5332 reutiliza 0x8848 en contextos Ethernet y GRE multicast para señalar asignación aguas arriba, pero ni ese código ni PPP, GRE o el protocolo IP 137 prueban por sí solos contexto, replicación, recepción o impacto.

El requisito de la base creó un hecho

Supongamos que un colector recibe una trama PPP con protocolo 0x0281 y una pila MPLS. La tabla de destino exige UPSTREAM o DOWNSTREAM; no admite un estado desconocido. El transformador elige DOWNSTREAM porque es el valor por defecto más frecuente. Horas después, un informe afirma que el receptor había asignado la etiqueta.

La captura nunca dijo eso. RFC 5332 trata PPP como un enlace punto a punto. En una dirección determinada, todas las tramas usan etiquetas superiores de una sola procedencia. El modo se establece por procedimientos externos y, si no existe otra información, debe usarse asignación aguas abajo. Pero un valor aplicado como regla operativa necesita registrar que fue un default normativo, no un bit observado.

La diferencia permite revisar el sistema. observed, contract, defaulted y unknown son estados de procedencia distintos. Fundirlos en un enum sin origen convierte una decisión local en historia del cable.

El antiguo nombre del EtherType tampoco salva el hueco

RFC 3032 describía dos codepoints MPLS como unicast y multicast. RFC 5332 explica que el uso multicast nunca se desplegó y que el desarrollo posterior necesitaba distinguir otra cosa. La lectura anterior queda obsoleta.

En una trama Ethernet multicast, 0x8847 se usa cuando la etiqueta superior fue asignada aguas abajo; 0x8848 se reserva para el caso en que fue asignada aguas arriba. Ambas tramas son multicast. La semántica de replicación se encuentra en la NHLFE a la que lleva la etiqueta dentro de su contexto.

Por eso no es correcto copiar la etiqueta «MPLS multicast» desde un registro antiguo a todos los medios. El número compartido coordina el formato. Su significado depende de dirección exterior, soporte y versión de la norma.

La procedencia indica qué pregunta viene después

Si el receptor asignó la etiqueta, creó y anunció la relación label-FEC. Si la asignó el emisor o un tercero, el receptor necesita interpretar un espacio de etiquetas que no tiene por qué ser el mismo. RFC 5331 proporciona las reglas de contexto para ese segundo caso.

El codepoint no selecciona automáticamente la tabla correcta. Tampoco demuestra que el vecino admite asignación aguas arriba. RFC 5332 prohíbe usar la función si no se sabe que el LSR aguas abajo la soporta, pero deja fuera de alcance cómo se obtiene ese conocimiento.

Una fila completa requiere identidad del par, evidencia de capacidad y su vigencia, contrato de dirección, selector de contexto, pila bruta y resultado de lookup. El campo de encapsulación es la puerta a esa investigación, no su conclusión.

GRE combina dirección exterior y contrato

En GRE con destino IP unicast, se utiliza 0x8847 en todos los casos. Con destino multicast, 0x8847 corresponde a etiqueta superior asignada aguas abajo y 0x8848 a asignación aguas arriba.

Además, si otros procedimientos establecen que un túnel multicast concreto debe transportar etiquetas asignadas aguas arriba, encontrar 0x8847 es un error y el paquete se descarta. El criterio no vive dentro de cuatro dígitos hexadecimales: aparece al unirlos con el contrato del túnel.

Un motor de cumplimiento debe mostrar esa unión. También debe separar el descarte requerido de sus consecuencias. Que el receptor deba descartar no prueba que el paquete llegara a ese receptor, que el software ejecutara la regla o que un servicio perdiera tráfico.

Protocolo 137 permanece deliberadamente indiferente

Cuando MPLS viaja directamente sobre IP, el campo IPv4 Protocol o IPv6 Next Header vale siempre 137, haya o no semántica multicast dentro. Si el destino IP es multicast, el túnel usa una dirección de asignación uniforme, elegida por mecanismos que RFC 5332 no define.

Una correlación que interprete 137 como «MPLS multicast» mezcla encapsulación con comportamiento. Otra que lo interprete como «upstream» mezcla protocolo con contrato. En ambos casos, el sistema rellena una dimensión que la evidencia dejó abierta.

Preservar lo desconocido permite buscar el registro correcto. Inventarlo puede seleccionar un espacio de etiquetas equivocado y convertir después el fallo producido por la automatización en aparente prueba de su propia hipótesis.

Los veinte bits de la MAC admiten dos políticas

La dirección Ethernet multicast para MPLS sigue 01-00-5e-8v-wx-yz. vwxyz puede ser cero o tomar el valor de una etiqueta de la pila. Si hay varias, el valor por defecto es el de la segunda; una configuración puede escoger otra. Si solo hay una, se usa esa.

Dos LSR conformes pueden elegir políticas distintas y deben interoperate. No se puede rechazar todo sufijo cero ni todo sufijo no cero. La información derivada de la etiqueta puede ayudar a filtrar, pero la norma no define los usos de ese filtrado.

El analista debe conservar la política de derivación, la etiqueta elegida, la pila original y la decisión del filtro. vwxyz no es identidad de usuario, suscripción al grupo ni prueba de entrega. Es un dato de direccionamiento con ambigüedad permitida.

La seguridad no convierte incertidumbre en atribución

RFC 5332 advierte que alterar maliciosamente el codepoint puede causar pérdida o reenvío incorrecto. También dice que cambiar solo el codepoint sin cambiar la etiqueta no produce un efecto predecible. Alterar la MAC DA puede enviar tramas a un tercero.

Una observación inconsistente permite afirmar exactamente eso: hubo una combinación que no coincide con el contrato o con la norma aplicable. Para atribuir intención hacen falta pruebas del cambio y del actor. Para afirmar desvío hacen falta lookup, interfaz de salida y recepción. Para declarar impacto hace falta la cadena de servicio.

El exceso de certeza es especialmente peligroso aquí porque el resultado depende del estado no visible: espacio de etiquetas, NHLFE, filtros y topología. Un modelo que oculta esos desconocidos no reduce riesgo; lo desplaza fuera del registro de auditoría.

Diseñar el esquema desde la evidencia

El esquema mínimo debería guardar medio, dirección exterior, codepoint, pila MPLS, origen de la interpretación, contrato de asignación y época, capacidad del par, contexto, lookup, política MAC, filtro, réplica, recepción y resultado. Ninguna columna posterior debe rellenarse automáticamente por proximidad nominal.

También hace falta un historial de significado. El cambio de RFC 3032 a RFC 5332 demuestra que la estabilidad numérica no garantiza estabilidad semántica. Cada dato decodificado debe indicar con qué versión se interpretó y conservar suficiente material para ser reinterpretado.

Así se mantiene delgado el plano común. La norma coordina lo imprescindible; el operador conserva sus contratos; el sistema en ejecución produce hechos; y la analítica no reclama autoridad sobre una realidad que no observó.

Fuentes