Resumen

  • La revisión 15 propone un enlace Ethernet emulado sobre HTTP, pero el principal autenticado en HTTP y la dirección MAC de origen declarada en cada trama son afirmaciones distintas.
  • 101 o 2xx establece el túnel; la admisión de la trama, el significado del VLAN, la prevención de bucles, la salida y el resultado requieren comprobantes independientes.

El 30 de septiembre de 2026 se publicó la revisión 15 de draft-ietf-masque-connect-ethernet. Es un documento activo del grupo MASQUE con nivel previsto Proposed Standard. Datatracker lo mantiene en evaluación del IESG, subestado AD Followup, y la nueva revisión devolvió la revisión de IANA a “Version Changed - Review Needed”. Sigue siendo un Internet-Draft: no es un RFC ni prueba adopción, despliegue, conformidad o rendimiento.

El mecanismo lleva tramas Ethernet entre un cliente HTTP y un proxy unido a un segmento físico o virtual. HTTP/1.1 negocia con GET, Upgrade: connect-ethernet y un 101 Switching Protocols. HTTP/2 y HTTP/3 usan Extended CONNECT y :protocol = connect-ethernet; una respuesta 2xx válida inicia el Capsule Protocol. El flujo de la solicitud delimita la vida del túnel.

El alcance exacto del éxito

El borrador dice que la respuesta satisfactoria indica que el proxy estableció el túnel y acepta transportar tramas. Ésa es toda la autoridad que debe heredar un indicador “activo”. Aún no existe comprobante de una trama futura.

El transporte debe ir protegido por TLS, QUIC o una protección equivalente. Así se protegen confidencialidad, integridad y autenticación de la relación de transporte. Sin embargo, una sesión autenticada no firma de forma automática cada dirección MAC de origen dentro de ella. El borrador permite tramas arbitrarias y advierte que una fuente MAC arbitraria puede facilitar suplantación, envenenamiento de ARP, NDP o tablas CAM y denegación de servicio.

Por eso la pregunta “¿quién abrió el túnel?” no sustituye a “¿quién puede hablar como esta MAC?”. Tampoco sustituye a “¿qué destinos, EtherTypes o VLAN puede alcanzar?”. Una autorización asignada sólo a la URI puede ser demasiado amplia para el poder de capa 2 que activa.

Contexto cero no significa identidad cero ambigua

Las tramas viajan en HTTP Datagrams. El Context ID 0 identifica el formato Ethernet: desde la dirección de destino hasta el byte anterior al FCS. El FCS no se transporta, pues normalmente se elimina al entrar y se regenera al salir. Esto reduce sobrecarga, pero también ilustra una separación fundamental. La integridad del túnel y un FCS nuevo protegen transmisiones concretas; no establecen la procedencia del encabezado original.

Los contextos distintos de cero se reservan para extensiones. Su registro puede adelantarse o retrasarse respecto de un datagrama por reordenación. Un receptor puede descartar un contexto desconocido o almacenarlo brevemente. El número sólo tiene sentido dentro de una solicitud: no es una identidad global ni un permiso durable.

La política MAC vive fuera de la respuesta HTTP

El borrador sugiere controles locales: limitar una conexión punto a sitio a una MAC, configurar direcciones permitidas, emplear IEEE 802.1X, autorizar usuarios y limitar tasas. No define una negociación dinámica de filtros MAC. Esa omisión no es un fallo oculto; delimita el protocolo. La implantación debe decidir y demostrar su política.

Un registro útil enlaza principal HTTP, versión de política, URI, fuentes autorizadas, vigencia y decisión por trama. Si una máquina virtual añade una MAC, si el equipo se reemplaza o si un acceso de emergencia amplía el conjunto, el cambio necesita propietario y caducidad. Sin ello, una excepción temporal se convierte en capacidad permanente.

VLAN y puente: dos estados que no caben en “arriba”

Las etiquetas 802.1Q pasan transparentemente por defecto. Cuando una extremidad las interpreta, ambos lados necesitan un acuerdo señalizado o manual que el documento no define. Cada VLAN puede asociarse a una URI; también puede retirarse una etiqueta y reaplicarse a la salida. Esto exige conservar la traducción exacta, no sólo el estado del túnel.

Al conectar el enlace emulado con una red externa aparecen funciones de puente que quedan fuera del protocolo: difusión, multidifusión, tramas PAUSE, aprendizaje y prevención de bucles. Dos túneles correctos pueden cerrar un ciclo incorrecto y generar una tormenta de broadcast. STP/RSTP, una topología demostrablemente libre de bucles, límites de tráfico y supervisión pertenecen al sistema operativo del servicio.

La trama puede perderse sin que caiga el túnel

En HTTP/3, QUIC DATAGRAM no fragmenta. Si una trama no cabe, el extremo debe descartarla y no convertirla silenciosamente en cápsula. Las cápsulas pueden transportar una trama grande de forma fiable a través de varios paquetes, aunque el orden no está garantizado en todas las rutas, sobre todo si un intermediario recodifica el modo.

Después de desencapsular, una trama demasiado grande para la interfaz, la red de salida o el receptor debe descartarse. Si el extremo no puede entregarla al segmento subyacente, también se descarta. El borrador recomienda contabilizar las pérdidas por tamaño. De este modo, un túnel sano puede transportar unas tramas y perder otras de manera determinista.

La cadena probatoria correcta registra: identidad y autorización HTTP; URI y respuesta; contexto y modo; decisión sobre fuente MAC; tratamiento VLAN; estado del puente; tamaño y cola; resultado de interfaz; observación de destino. Un 200 encabeza la cadena. No la completa.

Como lente editorial declarada, los textos de Heng Lu sobre código en funcionamiento, especificación inicial mínima y agencia ayudan a leer esta frontera. El estándar compartido coordina un enlace; los sistemas locales conservan la decisión y la obligación de probar quién puede producir efectos en el dominio de difusión. Es una interpretación analítica, no una atribución de intención al IETF.

Fuentes