Resumen

  • RFC 948 comparó en junio de 1985 una encapsulación compatible con Ethernet y otra ajustada a IEEE 802.2/802.3. El campo que Ethernet interpretaba como tipo de protocolo era longitud en 802.3. La coincidencia del soporte físico no hacía interoperables a los anfitriones que eligieran formatos distintos.
  • Ira Winston prefería el método IEEE, pero propuso instalar primero una selección estática en todos los equipos y conservar temporalmente el formato Ethernet. Cambiar antes de que el último anfitrión estuviera listo dividiría la red; un puente mediante pasarela añadiría un coste de rendimiento importante.

La trampa de un campo familiar

Los dos encabezados parecían parientes. Ethernet Version 2.0 y 802.3 compartían una capa física compatible para fines prácticos, señaló RFC 948. Después venía la discrepancia: dos bytes que en un caso nombraban el protocolo contenido y en el otro indicaban la longitud. Una tarjeta podía recibir señales perfectamente y entregar al software una envoltura que este interpretaba con las reglas equivocadas. La electricidad había llegado; el acuerdo sobre el idioma del paquete, no.

La solución que miraba hacia atrás conservaba el formato de tipo de Ethernet. En una red 802.3 de 10 Mbit/s, el valor de longitud permitido llegaba a 1500. El documento decía que valores superiores podían usarse privadamente, y los tipos correspondientes a IP, ARP y encapsulación con tráiler superaban ese límite. Así, una conexión física compatible con 802.3 podía seguir emitiendo tramas entendibles para el parque Ethernet. Era una salida para la base instalada, no una prueba de que ambos encabezados fueran equivalentes.

La segunda opción usaba LLC de IEEE 802.2. IP se colocaba en una trama Type 1 Unnumbered Information con DSAP y SSAP iguales a 96, el SAP global de IP citado en la propuesta. Cuando 802.3 exigía relleno hasta un mínimo físico, los ceros añadidos quedaban fuera del datagrama IP. El texto admitía una tabla estática de direcciones, aunque recomendaba con fuerza la búsqueda dinámica parecida a ARP. Todo ello permitía construir una red coherente de máquinas que hablaran el segundo formato. La máquina que siguiera enviando el primero pertenecía a otra conversación.

El último equipo decidía el día

Winston explicó el coste de mezclar sin coordinar: un solo LAN físico terminaba convertido en dos subredes IP incompatibles. Un ordenador capaz de hablar ambos formatos podría actuar de pasarela entre ellas, pero el RFC advertía una penalización de rendimiento significativa. El camino de los datos ya no era el que sugería el plano de cableado. Dos equipos próximos necesitaban que otro tradujera la frontera de enlace.

La preferencia del autor era la encapsulación IEEE 802.2/802.3, respaldada por normas aceptadas nacional e internacionalmente y reutilizable en otras redes físicas IEEE 802. Pero había instalaciones Ethernet funcionando. Su plan tenía orden: dotar a equipos nuevos y existentes de elección estática; mantener a todos en el método compatible con Ethernet mientras se desplegaba esa capacidad; pasar conjuntamente al método IEEE solo cuando ningún equipo faltara. No era una ceremonia burocrática. La ventana común era parte del diseño técnico.

RFC 1042, de febrero de 1988, registró una solución IEEE posterior con LLC/SNAP en lugar del SAP 96 directo de RFC 948. En ella DSAP y SSAP valían 170 y seguían un código de organización cero y un EtherType. También precisó el límite que un cable mixto podía esconder: los paquetes de difusión de enlace solo llegaban a los receptores que usaban el mismo formato. Si resultaba necesario mezclar, recomendaba una pasarela IP como entre dos redes distintas. Esta especificación posterior documenta otro encabezado y el mismo problema de convivencia; no cuenta que la migración de Winston se ejecutara en una instalación concreta.

La ironía de RFC 948 es sencilla. El operador podía pagar por compatibilidad física y recibir dos redes. La diferencia estaba en una regla de lectura y en el momento de cambiarla. Un calendario de migración podía resultar tan importante para IP como la propia interfaz.

Fuentes