Resumen
draft-ietf-snac-simple-12conecta automáticamente una red terminal IPv6 con infraestructura adyacente mediante estados distintos de direccionamiento, ruta y descubrimiento.- Tras un reinicio o relevo, el prefijo nuevo puede coexistir con direcciones y rutas antiguas aún válidas; el temporizador no identifica qué dirección eligió cada aplicación.
- La continuidad necesita un recibo local que conserve causa, transición, vidas útiles, ruta instalada, descubrimiento y prueba de la transacción concreta.
La validez no elige por el host
El propósito del router SNAC es práctico: unir una red terminal de dispositivos restringidos con un enlace Wi-Fi o Ethernet sin convertir medios incompatibles en un falso dominio de capa dos. La automatización se apoya en IPv6 Neighbor Discovery, prefijos on-link, rutas específicas, DNS-SD y, en algunos casos, DHCPv6-PD y NAT64.
El resultado parece una sola función, pero la revisión 12 habla de direccionabilidad, alcanzabilidad y descubrimiento por separado. Esa taxonomía es más honesta que muchos paneles. Un nombre visible no instala una ruta; una ruta no obliga a escoger una dirección; una dirección válida no entrega el comando.
El estado adecuado depende de tiempo y vecino
Al conectarse al enlace de infraestructura adyacente, el router busca anuncios según el RFC 4861. Con un prefijo on-link adecuado entra en STATE-SUITABLE. Sin él, pasa a STATE-BEGIN-ADVERTISING y genera uno.
La comprobación tiene dos ejes. STALE_RA_TIME, diez minutos por defecto, impide confiar en un Router Advertisement demasiado antiguo. La detección de inalcanzabilidad comprueba además al router anunciante, con sesenta segundos como tiempo máximo adecuado antes de sondearlo. Un vecino que responde pero dejó de renovar RA y una RA reciente de un vecino ya caído son fallos distintos.
Este detalle limita la autoridad del mensaje. El PIO puede ser sintácticamente perfecto y su vida útil positiva, pero la fuente operativa que permite usarlo puede haber desaparecido.
La máquina de estados conserva un camino de vuelta
Cuando comienza a anunciar, el router da a su prefijo vidas preferida y válida de treinta minutos por defecto. Si aparece otro prefijo preferible, entra en STATE-DEPRECATING: anuncia el antiguo con vida preferida cero y reduce la válida. Si el sustituto desaparece antes de terminar, vuelve a anunciar el propio.
Esa reversibilidad evita una retirada precipitada. También crea un período legítimo de coexistencia. Un host que recibió el anuncio antiguo puede conservar la dirección; otro que se incorporó después solo conocerá la nueva. Un tercero pudo perder el multicast que deprecaba la primera. No existe un reloj central que sincronice esas memorias.
El RFC 8978 explica el problema general de renumeración instantánea. Sus ejemplos de siete días de preferencia y treinta de validez describen SLAAC general. SNAC usa treinta minutos por defecto para su prefijo suministrado. La diferencia numérica importa; la separación conceptual también: vida restante no es utilidad restante.
El relevo puede producir una dirección fantasma
En el escenario con dos routers, A anuncia un prefijo y se apaga. B toma el relevo con otro. Cuando A vuelve, observa el anuncio adecuado de B y no restablece el suyo. Sin embargo, algunos hosts siguen usando direcciones del prefijo de A.
A puede recibir ese tráfico sin considerar ya el prefijo on-link. Puede enviarlo al router predeterminado o descartarlo. El borrador anticipa la manifestación real: pérdida temporal de control de dispositivos y fallo de automatizaciones.
No es correcto resumirlo como «reiniciar cambia el prefijo». El texto espera persistencia para el ULA autogenerado y dice que DHCPv6-PD suele devolver el mismo bloque. Los cambios repetidos señalan otra causa: pérdida de estado, ausencia suficientemente larga, inestabilidad del enlace, concesión breve o distinta, o partición de la malla.
Compartir un /64 estable reduce el problema. Thread usa el Extended PAN ID como ingrediente estable. Pero el borrador condiciona la continuidad a que no reinicien simultáneamente todos los routers que sostienen esa red terminal.
La segunda superposición ocurre en OSNR
El prefijo OSNR sirve para comunicación fuera de la red terminal. Puede proceder de DHCPv6-PD conforme al RFC 9915 o de ULA conforme al RFC 4193. Si su único anunciante falta, otros routers pueden conservar la ruta antigua. Coordinar la preservación del mismo prefijo está fuera del alcance de la especificación.
Cuando se acerca la expiración, otro router puede anunciar su propio OSNR. Mientras tanto, los routers que recuerdan el anterior publican su ruta hasta que venza. Dos rutas válidas protegen conversaciones existentes, pero no prueban cuál usa una sesión nueva ni si ambas llegan al mismo fragmento de una malla.
Descubrimiento positivo, ruta negativa
RA Guard permite construir una prueba decisiva. Puede bloquear los RA del router SNAC en la infraestructura sin afectar mDNS. Los servicios siguen apareciendo, pero los hosts no reciben el RIO del RFC 4191 y carecen de ruta al OSNR. NAT64 puede mantener alguna salida, complicando aún más el indicador.
Por eso el diagnóstico compara la emisión registrada por el router, la ruta instalada en un host y el resultado de una aplicación. Los RFC 6762 y 6763 documentan descubrimiento, no continuidad integral.
Un recibo para el momento de desacuerdo
El texto recomienda registrar con tiempo las renumeraciones, depreciaciones, invalidaciones, cambios del router proveedor y pérdidas o retornos de la ruta predeterminada. El recibo operativo debe añadir identidad de router y arranque, alcance del prefijo, estado previo y nuevo, origen y edad del RA, resultado de vecindad, vidas anunciadas, comienzo de depreciación, RIO, ruta observada, descubrimiento y transacción con la dirección realmente escogida.
La propuesta no centraliza direcciones. Define el mínimo que permite comparar implementaciones y reconstruir una decisión local. Esa es la disciplina de especificación inicial mínima de Lu Heng. También respeta las capas de realidad: declaración, modelo local, condición de operación y evento de aplicación permanecen conectados sin confundirse.
Fuentes
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance