Resumen

  • RFC 9685 añade suscripciones multicast y anycast al registro de Neighbor Discovery de RFC 8505 y conserva la validación EDAR/EDAC cuando se comprueba el derecho del nodo a escuchar.
  • La inyección de la dirección en el protocolo de enrutamiento ocurre de forma asíncrona respecto de la suscripción, por lo que EDAC y NA(EARO) no son recibos de propagación RPL.
  • La cadena operativa debe conservar por separado la admisión, el estado por origen, la fusión, el DAO, la selección anycast o réplica multicast, la transmisión y la recepción de la aplicación.

El 6LoWPAN Border Router devolvió un EDAC correcto. El 6LR respondió al nodo con NA(EARO). La consola registró “suscripción aceptada” a las 10:14:03. El DAO que podía llevar aquella dirección a RPL apareció varios segundos después. Durante ese intervalo, una aplicación envió un paquete que nunca llegó al oyente.

No faltaba una validación retrospectiva. Faltaba reconocer que cada mensaje tenía un sujeto diferente. RFC 9685 hace explícita esa separación al indicar que la inyección de ruta es asíncrona respecto del registro. La respuesta de admisión puede ser correcta aunque el estado de enrutamiento aún no exista.

P, R y EDAC contestan preguntas distintas

La base de RFC 8505 registra direcciones unicast. RFC 9685 extiende el mecanismo para que un nodo se suscriba a una dirección que escucha o acepta. El P-field identifica multicast con el valor 1 y anycast con el valor 2. El indicador R, separado, solicita servicio de alcanzabilidad.

Por eso “P válido” no significa “ruta solicitada”. Y “R solicitado” no significa “ruta instalada”. El paquete NS(EARO) contiene además el Transaction ID, la vida útil y el Registration Ownership Verifier. Esos datos forman la identidad temporal de la operación, no una promesa de extremo a extremo.

Cuando el 6LR comprueba el derecho del host a escuchar, envía EDAR al 6LBR y recibe EDAC. La protección ROVR heredada de RFC 8928 dificulta que otra parte suplante la propiedad del registro. Pero la confirmación del registrar no autoriza una función de negocio, no instala por sí misma un DAO y no observa al receptor.

Un comprobante serio conserva, como mínimo, el NS(EARO), P, R, TID, ROVR, vida útil, identidad de enlace, EDAR, EDAC y NA(EARO). Luego abre una nueva etapa. Si la plataforma transforma todos esos hechos en “servicio activo”, ya ha atribuido a EDAC una autoridad que no tiene.

La asincronía debe medirse, no ocultarse

Una inyección asíncrona ofrece flexibilidad al router. También crea un intervalo que la operación debe poder observar. El inicio es la aceptación local de la suscripción; el final es un evento verificable de incorporación o actualización de la dirección en la instancia de enrutamiento correspondiente.

La latencia entre ambos no se deduce del orden ideal de un diagrama. Puede crecer por procesamiento, pérdida de control, reparación de topología o migración entre instancias. Un objetivo de servicio puede imponer un límite local, pero RFC 9685 no convierte el NA recibido por el nodo en prueba de que ese límite se cumplió.

La fusión complica el análisis. Varios nodos pueden suscribirse a la misma dirección. El router mantiene estado por origen, pero anuncia una sola ruta. Además, usa la vida útil más larga entre las suscripciones activas que piden alcanzabilidad. Un DAO preexistente puede seguir siendo válido aunque la nueva suscripción aún no se haya integrado correctamente en el estado por origen. Ver la ruta no demuestra que el nuevo oyente ya esté cubierto.

El registro operativo necesita correlacionar la nueva entrada con el conjunto fusionado: hora de admisión, hora de actualización del conjunto, vida útil efectiva antes y después, origen añadido o retirado, secuencia y hora de emisión del DAO. Sin esa correlación, una ruta antigua puede hacerse pasar por comprobante de una suscripción nueva.

El modo RPL cambia la naturaleza del recibo

En modo Storing de RFC 6550, los DAO construyen un árbol multicast a través de los padres preferidos. Cada router conserva información y reenvía tramas MAC unicast individuales por las ramas pertinentes.

En el nuevo modo multicast Non-Storing, la raíz realiza ingress replication. Las direcciones aparecen como Targets y la raíz encapsula copias hacia los 6LR de tránsito mediante el mecanismo de rutas de origen relacionado con RFC 9008. La evidencia exigible cambia: estado distribuido por rama en un caso; lista de destinos y decisión de réplica en la raíz en el otro.

El anycast no replica hacia todos. Aunque varias partes se suscriban a la misma dirección, un paquete se reenvía a una sola. La aceptación de tres suscripciones no prueba tres entregas, ni siquiera cuál fue elegida. Deben conservarse la política local, el candidato seleccionado, la ruta y el resultado.

RFC 6553 y RFC 9008 aportan elementos del plano de datos. RFC 3810 define MLDv2 y RFC 7731 define MPL para otro tratamiento de multicast en redes de baja potencia. Un sistema de observabilidad debe identificar el mecanismo real y no mezclar contadores de familias distintas.

La pérdida puede ocurrir después de que toda señalización parezca correcta

RFC 9685 reconoce que Direct MAC Broadcast puede ser poco fiable y que la transmisión asíncrona perjudica a nodos que duermen. La entrega como tramas MAC unicast individuales es preferible cuando resulte posible. Aun así, “trama transmitida” no significa “aplicación informada”.

El estado también puede desaparecer. Si un router reinicia sin persistir registros, debería pedir una actualización asíncrona. Si no lo hace, la recuperación puede demorarse hasta el siguiente registro periódico y los paquetes pueden perderse. La base de datos central puede conservar el EDAC histórico mientras el 6LR ya no conserva la entrada que hacía útil aquel intercambio.

La cadena final necesita un evento de inyección, propagación DAO, estado de Root o de routers intermedios, decisión de réplica o selección, transmisión de enlace, recepción IP y confirmación de aplicación. Cada paso puede fallar sin falsificar el anterior.

La selección de alcance tampoco cierra la cadena. RFC 7346 define alcances IPv6 multicast; RFC 9685 relaciona Realm-Local con un DODAG y Admin-Local con una instancia federada. Elegir el alcance correcto delimita la intención, pero no demuestra cobertura topológica.

MOP 5 exige migración, no un cambio instantáneo

RFC 9685 advierte que una red en funcionamiento no puede actualizar su instancia actual a MOP 5 sin más. El administrador crea otra instancia y migra nodos. En un entorno con equipos heredados puede mantener un MOP para unicast y otro para multicast o anycast.

La cobertura depende entonces de que haya suficientes 6LR capaces de aceptar oyentes. En Storing, también deben formar un DODAG hasta la raíz. Una opción de capacidad anuncia una posibilidad; no prueba la densidad, la adhesión de cada nodo ni el camino vigente.

La especificación inicial mínima permite acordar el intercambio sin centralizar la decisión de despliegue. Las capas de realidad evitan que validación, ruta y resultado se conviertan en una sola etiqueta. La prioridad del código en ejecución obliga a buscar el recibo allí donde el paquete fue tratado.

RFC 9685 mejora la seguridad al permitir que una RPL-Unaware Leaf obtenga servicio sin autoridad para inyectar mensajes RPL. La misma limitación debe regir el lenguaje de operación. EDAC certifica su intercambio. RPL certifica su estado. La aplicación debe certificar su recepción.

Fuentes