Resumen

  • IEEE Registration Authority asigna EtherTypes y LSAP, y entregó a IANA el OUI 00-00-5E; la facultad de IANA se limita a los subespacios derivados de esa delegación.
  • Los dos octetos posteriores al OUI no se convierten en EtherType por su tamaño ni por su cercanía al inicio de la trama.
  • Una afirmación verificable necesita posición, encapsulado, namespace, registro autoritativo, procedimiento, especificación y evidencia de ejecución.

El error nació de una normalización aparentemente inocente. Un sistema de activos tenía una columna de dieciséis bits llamada “tipo de protocolo”. De una trama con 88-B7-00-00-5E-00-42 tomó el último par, descartó el prefijo y lo comparó con una tabla alojada por IANA. El resultado parecía preciso: valor hexadecimal, nombre de registro y enlace de referencia.

Sin embargo, 0x0042 no era el EtherType. 0x88B7 cumplía esa función. Los tres octetos intermedios nombraban al dueño del subespacio, e IANA había reservado el número interior para documentación. La automatización había construido una procedencia falsa con datos auténticos.

RFC 9542 permite deshacer ese nudo. El documento es BCP 141, se publicó en abril de 2024 y dejó obsoleta RFC 7042. No creó registros nuevos ni reasignó valores. Su aportación central es más disciplinada: mostrar que un mismo dibujo de trama puede atravesar varias autoridades sin que una absorba a la otra.

Tres formas que no deben caber en una sola columna

Un EtherType es un identificador de dieciséis bits con valor igual o superior a 0x0600. IEEE RA lo asigna. En una trama Ethernet II sencilla aparece después de las direcciones MAC, aunque las etiquetas pueden introducir más campos de tipo.

LLC usa otra estructura. Un campo de longitud precede a dos LSAP de ocho bits. SNAP añade AA-AA-03, después un OUI y finalmente un número de protocolo de dos octetos. En ese caso, el titular del OUI controla el último número.

Existe además el EtherType de extensión OUI 0x88B7. Su función es anunciar que vienen un OUI y un número de protocolo. En 88-B7-00-00-5E-qq-qq, IEEE asignó el portador y el OUI; IANA administra qq-qq dentro de la porción que recibió. El hecho de que el campo exterior y el interior midan lo mismo no los hace miembros del mismo registro.

SNAP admite también un OUI completamente nulo seguido de un EtherType cualquiera. Allí los dos octetos finales sí representan el EtherType. La diferencia entre 00-00-00 y 00-00-5E cambia la autoridad competente. Por eso una base que conserva solo el sufijo no tiene suficiente información para interpretar su propio dato.

La autoridad no se deduce del dominio web

IANA mantiene “IANA OUI Ethernet Numbers” para las asignaciones realizadas bajo su OUI. El registro de números de protocolo SNAP muestra 0x0042 como valor de documentación. Esa página sí documenta una decisión dentro de la competencia de IANA.

En el mismo sitio existe “IEEE 802 Numbers”. La sección de EtherTypes advierte que IANA no los asigna y que la lista es información contribuida y no verificada. La autoridad sigue siendo IEEE RA. IANA coordina la presentación con expertos, pero publicar una copia no equivale a originar la asignación.

Esta diferencia puede desaparecer al transformar HTML o XML en una tabla corporativa. Si el importador conserva filas pero no las notas de responsabilidad, todas las fuentes adoptan el mismo rango. La firma del archivo solo acredita que nadie lo alteró después; no corrige una atribución institucional equivocada.

Para sistemas de seguridad, la pérdida es concreta. Una regla puede abrir paso a una supuesta norma, bloquear una prueba local o aceptar un ejemplo documental. El número solo no indica cuál de esas políticas corresponde. La procedencia debe formar parte de la clave, no quedar en una nota opcional.

Las condiciones de IANA son parte del significado

Un nuevo número de protocolo bajo 00-00-5E debe destinarse a una norma IETF o relacionada, estar documentado en un Internet-Draft o RFC y proporcionar un campo de versión fijo o mecanismo equivalente. La revisión ordinaria es Expert Review. Los extremos 0x0000 y 0xFFFF están reservados y necesitan ratificación del IESG.

RFC 9542 prohíbe asignar uno de esos números a un protocolo que ya dispone de EtherType. Puede usarse el EtherType directamente o dentro de SNAP con el OUI nulo. La política evita multiplicar identificadores y, sobre todo, evita que dos cadenas de autorización parezcan intercambiables.

La lógica se repite en los bloques de direcciones MAC bajo el OUI IANA. Deben servir a estándares, respetar tamaños y alineamientos en potencias de dos y no utilizarse para eludir la obligación de que un fabricante obtenga su propio bloque IEEE. La subdelegación tiene un propósito, y el propósito limita el poder.

Documentar y experimentar no son sinónimos

IANA reservó 0x0042 bajo su OUI para ejemplos. En otros parámetros organizativos, el valor adicional 0x42 cumple el mismo cometido. Así un documento puede mostrar un identificador concreto sin ocupar el espacio de un protocolo real.

IEEE, por otro lado, asignó 0x88B5 y 0x88B6 como EtherTypes de uso experimental local. Son valores distintos, en un registro distinto y con un alcance distinto. El rótulo “EtherType experimental 0042” mezcla ambos regímenes y puede convertir una muestra en una autorización que nunca existió.

Los laboratorios suelen copiar configuraciones. Una plantilla con un valor documental puede terminar en producción; un EtherType experimental puede cruzar el límite administrativo donde dejó de ser seguro. Registrar el ámbito y la fecha junto al valor ayuda a descubrir esa deriva antes de que se vuelva dependencia.

Nueve recibos, no una única celda

La primera prueba es la posición exacta de los bytes. La segunda es el portador: EtherType directo, LLC/SNAP o extensión OUI. La tercera es el namespace completo. Luego vienen el registro autoritativo, el procedimiento de aprobación y la especificación.

Después empieza la realidad operativa. La versión y configuración del analizador muestran qué hizo una implementación concreta. La captura demuestra qué atravesó un punto de observación. El extremo receptor demuestra el efecto. Una asignación registral no sustituye ninguna de estas tres últimas pruebas.

La separación protege tanto al operador como al registro. IEEE e IANA pueden coordinar unicidad sin asumir responsabilidad por cada decodificador o aplicación. El fabricante puede demostrar comportamiento sin reclamar autoridad sobre el namespace. El incidente deja de ser una disputa de nombres y se convierte en una cadena que puede auditarse.

Diseñar el inventario para conservar la pregunta correcta

El registro interno debería almacenar los bytes crudos, offsets, etiquetas, portador, OUI, valor interior, dueño del registro, fuente, fecha de consulta, clase de política, documento y resultado del parser. Un nombre amigable puede acompañarlos, pero nunca reemplazarlos.

Con ese modelo, una discrepancia tiene solución. Una lista informativa desactualizada se compara con IEEE RA. Un número válido de IANA mal rotulado por un disector se corrige en la capa de presentación. Una reserva documental observada en producción abre un incidente de asignación y migración. Sin ese contexto, todo se reduce a elegir qué tabla parece más convincente.

RFC 9542 no pide más autoridad central. Pide contabilidad más fina. IEEE conserva el espacio que administra; IANA conserva el subespacio que recibió; el código en funcionamiento conserva la obligación de demostrar lo que realmente hizo. La gobernanza se vuelve más fiable al negarse a borrar las fronteras.

Fuentes