Resumen

  • La figura de RFC 8928 situaba C en el bit 3 de EARO, pero esa posición no quedó registrada en IANA; RFC 9685 registró después el campo P de dos bits en las posiciones 2 y 3.
  • RFC 9927 traslada C al bit 1 y declara que el cambio no es retrocompatible. No define una transición porque sus autores no conocían implementaciones ni despliegues de RFC 8928.
  • El RFC y el registro corregidos establecen la asignación coordinada actual, no la versión de un binario, la lectura de un paquete ni el estado de un servicio.

El error estaba entre dos fuentes de autoridad

RFC 8928 especificó Address-Protected Neighbor Discovery. Dentro de la Extended Address Registration Option, C indica que el Registration Ownership Verifier contiene un Crypto-ID y que el nodo 6LoWPAN puede ser desafiado para demostrar la propiedad de la dirección registrada. Su figura colocó C en el bit 3.

La descripción era suficientemente concreta para orientar código. Lo que faltó fue registrar el valor en el espacio compartido de IANA. Esa omisión crea una asimetría peligrosa: quien implementa la figura cree que la posición está ocupada; quien diseña una extensión y consulta el registro cree que sigue disponible. Ambos pueden actuar de buena fe y terminar con gramáticas incompatibles para el mismo octeto.

RFC 9685 introdujo después el Registered Address Type Indicator. Su campo P abarca los bits 2 y 3 y sí pasó por el registro correspondiente. El resultado fue un solapamiento real en el bit 3. No era una discusión de nombres: un receptor podía interpretar la misma posición como C o como parte de P.

Las fuentes no documentan que esa posibilidad llegara a causar una avería o una incompatibilidad observada. Sí demuestran que los documentos publicados permitían dos lecturas.

Una posición nueva y un mapa común

RFC 9927 sustituye las figuras EARO afectadas de Neighbor Solicitation y Neighbor Advertisement. C pasa al bit 1; P conserva los bits 2 y 3. La corrección también cambia la denominación errónea «Enhanced Address Registration Option» por «Extended Address Registration Option».

El registro actual de IANA ofrece una distribución única: bit 0 sin asignar; bit 1 para C; bits 2–3 para P; bits 4–5 para I; bit 6 para R; bit 7 para T. La utilidad del registro no consiste en decorar la especificación. Consiste en que el siguiente autor o implementador pueda conocer el estado del espacio de valores sin reconstruirlo desde una cadena de ilustraciones.

RFC 8126 proporciona el marco procesal: una asignación de protocolo requiere una política de registro porque coordina decisiones independientes. Aun así, el alcance de esa autoridad termina en la convención. IANA puede decir qué significa hoy una posición dentro del sistema de estándares. No puede confirmar que un dispositivo concreto recibió una actualización o que un paquete se procesó con esa tabla.

El dato decisivo también contiene incertidumbre

RFC 9927 reconoce que el traslado no es retrocompatible. Un emisor basado en la figura antigua y un receptor basado en la asignación nueva pueden discrepar. Pese a ello, el documento no prescribe un plan de transición porque no había implementaciones ni despliegues conocidos de RFC 8928.

La palabra «conocidos» no es ornamental. Registra el horizonte de información de los autores, no el resultado de un censo universal. No demuestra que nadie escribiera un prototipo, que no existiera código privado ni que toda organización revisara sus repositorios. Convertir esa frase en «no existía nada» sería añadir una certeza que la fuente no ofrece.

Por eso la respuesta local depende del inventario. Una organización sin rastro de RFC 8928 puede tomar RFC 9927 como punto de partida. Si aparece una implementación anterior, deberá identificar versiones, conservar procedencia de compilación, probar codificadores y analizadores con vectores controlados, observar la conducta de los pares y definir reversión. Que el estándar no imponga una transición global no elimina una necesidad local demostrada.

La coordinación y la ejecución necesitan pruebas distintas

El modelo de Minimum Initial Specification de Heng Lu ayuda a interpretar el caso, aunque no sea una norma del IETF. Una regla común mínima puede coordinar el espacio compartido y dejar la adopción a cada participante. Running-Code Primacy recuerda que el estado de los sistemas no cambia por la autoridad del papel. Reality Layers evita que una verdad normativa se presente como una verdad operacional.

Cada fuente, por tanto, responde a una pregunta. RFC 8928 prueba qué dibujó. RFC 9685 y la acción de IANA prueban la asignación coordinada de P. RFC 9927 prueba la corrección normativa y el razonamiento de transición. El registro vivo prueba el mapa vigente. Ninguno, por sí solo, identifica cómo analiza el campo un binario sin nombre.

Una afirmación sobre ejecución exige versión de fuente o binario, comportamiento del codificador y decodificador, configuración, pruebas o capturas controladas, versión del par y observación del resultado. Una afirmación sobre servicio necesita además una medición de servicio. «El registro está corregido» no equivale a «la red está corregida».

Lo que este expediente no afirma

No hay un producto, despliegue, paquete, explotación, caída, porcentaje de adopción o efecto comercial acreditado. C tampoco demuestra titularidad pública de una dirección, autorización global de rutas ni aceptación del servicio; su función se limita al mecanismo de verificación de propiedad de EARO.

La conclusión útil es un límite doble. Una figura capaz de enseñar a programar debe estar unida al registro que coordina el campo. El registro corregido debe permanecer separado de la evidencia que describe el software en funcionamiento. RFC 9927 completa la primera unión, no la segunda.

Fuentes