Resumen

  • RFC 2067 prohibió el burst corto inicial, el relleno D1 y el desplazamiento D2 distinto de cero que RFC 1374 había permitido.
  • La justificación fue operacional: ninguna implementación en uso empleaba esas opciones; no fue una afirmación sobre todo código posible.
  • El resultado solo prometía interoperabilidad con un conmutador HIPPI-SC o un enlace bidireccional punto a punto simple.

Tres campos dejaron de ser opcionales y, con ello, el contrato compartido se volvió más pequeño. El burst corto, si existía, tenía que cerrar el paquete. El área D1 quedó fijada en tres palabras de 64 bits, sin relleno. El desplazamiento D2 quedó en cero. La forma que RFC 1374 recomendaba pasó a ser obligatoria.

Cada alternativa en el cable multiplica el trabajo fuera del documento: más ramas de análisis, más pares de compatibilidad y más estados que distinguir durante un incidente. Mantener una opción sin usuarios conocidos obliga a todos los implementadores a financiar una posibilidad que nadie puede mostrar funcionando.

Diez implementaciones no validaron cada función

RFC 2067 informó de al menos diez implementaciones de la encapsulación IP y la disciplina del conmutador desarrolladas bajo RFC 1374. También afirmó que las tres variantes eliminadas no eran usadas por implementaciones en servicio. Por eso esperaba que los sistemas existentes ya cumplieran el perfil nuevo.

La evidencia es importante precisamente porque es limitada. El RFC no enumera productos, autores independientes ni resultados de una matriz completa. No demuestra que nunca hubiera un prototipo privado con otra forma. Registra una observación suficiente para una decisión de ingeniería: la compatibilidad especulativa no debía pesar tanto como el comportamiento que sí había llegado al código operativo.

RFC 2026, publicado poco antes, exigía para Draft Standard dos implementaciones independientes e interoperables y experiencia operacional satisfactoria. El requisito alcanzaba opciones y funciones; las que no pudieran acreditarlo debían eliminarse normalmente. La edición de RFC 2067 convirtió esa regla de proceso en una reducción concreta del formato.

Un paquete ANSI válido podía quedar fuera

HIPPI-FP y HIPPI-LE describían un espacio más amplio. RFC 2067 declaró que su perfil era más restrictivo: un datagrama encapsulado podía ser válido conforme a ANSI y, a la vez, ilegal conforme al RFC. El destino podía aceptarlo o ignorarlo.

No existe, por tanto, una sola etiqueta de «cumple estándares». La conformidad ANSI acredita una envoltura dentro del estándar de enlace. La conformidad RFC identifica el subconjunto que un par IP puede exigir. Confundir ambos recibos convierte capacidad del hardware en una obligación de Internet que el documento nunca otorgó.

ARP perdió el derecho a viajar con IP

RFC 1374 había unido encapsulación IP y resolución de direcciones. La primera acumuló experiencia; ARP no. RFC 2067 sacó ARP del texto de avance y lo trasladó a un memorando Informational, susceptible de volver si aparecían interés e implementaciones.

Así, la evidencia de un componente no maquilló al otro. Transferir un paquete IP no prueba descubrimiento de direcciones, configuración de red o emulación de difusión. RFC 2834 retomó en 2000 ARP y broadcast IP sobre HIPPI-800 con aclaraciones y formatos adicionales. La separación dejó visible qué parte necesitaba aún trabajo.

La topología fijó el borde de la afirmación

Los nodos conformes se consideraban interoperables tras un único conmutador HIPPI-SC y también en una conexión directa de ida y vuelta. Las redes más complejas podían funcionar, pero dependían de la arquitectura interna y de cómo se enlazaban los conmutadores.

Un solo conmutador se trataba como no bloqueante. Al encadenar varios, un enlace compartido puede estar ocupado por otra pareja y negar temporalmente el camino. La estrategia necesaria en ese fabric no se deduce de un encabezado correcto. RFC 2067 la dejó fuera de su garantía.

Un registro de paquete puede verificar tamaño D1, offset y posición del burst. No prueba entrega a la aplicación, ausencia de contención, identidad, autorización ni seguridad. La frase del RFC sobre no introducir problemas de seguridad conocidos tampoco ofrece autenticación o cifrado.

El marco posterior de Lu Heng sobre especificación inicial mínima permite leer este episodio como una capa común reducida a reglas deterministas respaldadas por interoperabilidad, con las decisiones topológicas fuera de ella. Es una lectura editorial posterior, no la intención atribuida al autor. La lección histórica ya aparece en los RFC: el código en ejecución justificó quitar opciones y el alcance del ensayo impidió prometer más de lo observado.

Fuentes