Resumen

  • RFC 3378 registró EtherIP, un mecanismo diminuto que anteponía dieciséis bits a una trama Ethernet y la transportaba en IPv4 bajo el número de protocolo 97.
  • El formato no incluía autenticación del par, integridad de la trama interior, secuencia, control del túnel ni prevención de bucles. Decapsular con éxito no significaba que una LAN segura se hubiera extendido hasta el destino.

Una LAN parece definida por las tramas que circulan en ella, pero gran parte de su significado está fuera de esas tramas. El cableado, los conmutadores, el perímetro administrativo y los supuestos de vecindad convierten ciertos protocolos locales en decisiones tolerables. EtherIP conservó la envoltura y desplazó el tráfico, no ese contexto.

RFC 3378 se publicó en septiembre de 2002 con categoría Informational. Documentó un protocolo diseñado e implementado en 1991 y 1992 y explicó la asignación histórica del número IP 97. Sus autores recomendaron el trabajo posterior de túneles de capa 2 y pseudowires antes que EtherIP para diseños nuevos.

Su cabecera tenía solo dos campos. Tras IPv4 venían cuatro bits de versión con valor tres y doce bits reservados a cero. Luego aparecía la trama Ethernet o IEEE 802.3 completa salvo el FCS. El receptor descartaba valores distintos, extraía la trama, calculaba un FCS nuevo y la transmitía en la LAN remota.

Comprobar esos bits era comprobar gramática. No identificaba al emisor ni autorizaba la dirección MAC. El protocolo no llevaba identificador de sesión, número de secuencia, negociación, señal de repetición ni verificación propia de la carga encapsulada.

Eliminar el FCS rompía la continuidad de la prueba. El control del primer enlace terminaba en la entrada. La RFC advirtió que el checksum de IPv4 no protegía la trama interna y esperó que un protocolo superior diera integridad. El FCS recién calculado a la salida podía validar el último salto aunque la carga hubiera cambiado antes.

Una estación final podía elegir algunas tramas. Una estación semejante a un puente podía escuchar promiscuamente y seleccionar según MAC de origen o destino, EtherType o VLAN. También debía excluir tráfico que seguía siendo local o podía encaminarse normalmente. Estas reglas pertenecían al entorno y no quedaban declaradas en los dieciséis bits.

El emisor tenía que averiguar la dirección IP del EtherIP remoto, normalmente a partir de la MAC destino. RFC 3378 no definió un descubrimiento universal. Por ello, un datagrama bien formado dependía de dos decisiones previas: qué tramas entraban y qué puerta remota representaba cada destino.

Los puentes introducían el riesgo de circulación infinita. Varias puertas podían capturar y reinyectar la misma trama, sobre todo si era broadcast o multicast. La especificación exigía restringir la topología a un árbol, pero dejó ese árbol a la persona que configuraba las estaciones. No había contador de saltos ni protocolo interno capaz de detener el error.

Así, cada regla podía ser localmente correcta y el conjunto seguir fallando. Una puerta enviaba lo que debía y la otra lo devolvía a un segmento anterior. Más encapsulación solo aceleraba la repetición; los contadores medían actividad, no progreso.

El túnel también alargaba el dominio de seguridad. Dejar pasar EtherIP por un cortafuegos podía habilitar comunicaciones arbitrarias. Mecanismos débiles aceptados entre supuestos vecinos se volvían peligrosos a distancia. La RFC puso VRRP como ejemplo y mencionó IPsec para proteger los datagramas exteriores.

RFC 2401 describe aquella arquitectura IPsec y RFC 4301 la reemplaza. Proteger el exterior puede autenticar pares y resistir cambios durante el tránsito. No decide si la regla de captura era legítima, si la topología carecía de bucles, si debía reinyectarse la trama o si la aplicación obtuvo un resultado válido.

RFC 2003 y RFC 2784 permiten comparar IP-en-IP y GRE. Más tarde, RFC 3931 añadió conexión de control y sesiones a L2TPv3; RFC 3985 organizó la arquitectura pseudowire y RFC 4448 trató Ethernet. Son desarrollos posteriores, no funciones ocultas de EtherIP ni evidencia de uso.

Las palabras normativas de RFC 2119 tampoco deben ampliarse. MUST obligaba a usar o comprobar ciertos bits. No garantizaba que el número 97 cruzara un cortafuegos ni que existiera confianza. IANA registra una interpretación compartida, no una certificación de despliegue o seguridad.

La especificación inicial mínima de Lu Heng explica por qué bastaron tan pocos bits para habilitar una función. Sus capas de realidad explican por qué esos bits no bastan como prueba. Selección, encapsulación, admisión del par, ruta, integridad, decapsulación, FCS nuevo, inyección y recepción son etapas diferentes.

La lección histórica no es que EtherIP trasladara una LAN. Trasladó una trama de manera reconocible. Topología, administración, confianza y consecuencias siguieron fuera de ella, esperando que el operador las construyera correctamente.

Fuentes