Resumen

  • RFC 9762 incorpora al PIO una preferencia positiva y específica por prefijo: el host compatible debería intentar DHCPv6-PD antes de formar nuevas direcciones individuales desde un prefijo compartido que también permite SLAAC.
  • P=1 no es una concesión. La cadena verificable separa el RA recibido, la decisión del cliente, la respuesta DHCP, la aptitud del prefijo, el binding y la ruta del relay, la selección de origen y primer salto, y el resultado del tráfico.
  • La falta de P no significa que DHCPv6-PD esté ausente. A la vez, una P recibida conserva los límites de confianza de los Router Advertisements y puede utilizarse para retrasar la configuración o inducir ciclos de REBIND.

Una auditoría encontró una interfaz sin ningún PIO que tuviera P activada. El informe automático convirtió el hallazgo en una conclusión rotunda: “DHCPv6-PD no disponible”. Sin embargo, el equipo seguía solicitando y renovando un prefijo porque tenía una configuración explícita para hacerlo.

La máquina no había infringido RFC 9762. El informe sí había inventado el inverso lógico de una señal deliberadamente unilateral. P dice que la red prefiere que ciertos clientes intenten delegación. El silencio no dice que deban dejar de intentarla.

Esa asimetría ayuda a entender todo el mecanismo. El nuevo bit no pretende describir el estado completo del servicio. Resuelve un problema de orden: orientar la elección del host antes de que una aplicación dependa de una dirección SLAAC que quizá deba retirarse poco después.

La preferencia llega antes que la dirección difícil de retirar

Si un host forma primero direcciones desde el prefijo compartido, las aplicaciones pueden abrir conexiones con ellas. Cuando llega después un prefijo exclusivo, mantener ambos conjuntos reduce la ventaja de escala del modelo; retirar el primero interrumpe flujos. Por eso RFC 9762 ubica la señal en el PIO del Router Advertisement.

Para un cliente capaz de ejecutar DHCPv6-PD, P=1 expresa la preferencia por el modelo por cliente de RFC 9663. La decisión pertenece al PIO concreto. Un prefijo global puede preferir PD mientras otro prefijo ULA sigue usando SLAAC. Dos proveedores de un host multihomed también pueden anunciar políticas distintas.

P no depende de los bits M y O del RA. Algunos equipos anteriores a RFC 9762 sólo arrancan PD cuando M u O está activo, por lo que una red que quiera incluirlos puede necesitar ambas señales. P y el bit autónomo A deben ser configurables por separado; cambiar P no autoriza al router a cambiar A de forma implícita.

Esa separación deja una alternativa. P y A pueden estar activados a la vez. Mientras respeta la preferencia, el host trata A como si estuviera apagado y no forma nuevas direcciones desde ese PIO. Si no obtiene un prefijo apto, puede dejar de procesar P en la interfaz y volver a SLAAC o IA_NA. RFC 4862 contiene las reglas de autoconfiguración actualizadas y RFC 4861 el marco de Neighbor Discovery. El bit cambia una rama de decisión, no sustituye esos protocolos.

Una lista temporal gobierna el arranque y la retirada

El cliente mantiene por interfaz una lista de los prefijos recibidos en PIO con P=1 y vida preferida distinta de cero. Cuando pasa de cero a un elemento debería comenzar a pedir prefijos, salvo que ya lo haga. Cuando expira la vida preferida, o llega un PIO con vida preferida cero, elimina esa entrada.

Si la lista queda vacía, el cliente sólo debería detener solicitudes o renovaciones cuando no tenga otra razón para continuar. Las vidas de prefijos ya delegados no cambian. El emisor del RA puede retirar su recomendación; no posee el reloj del lease concedido por el servidor DHCP.

Cuando la lista cambia y ya hay delegaciones, el cliente debe tratarlo normalmente como nueva información de configuración y hacer REBIND, excepto si la lista quedó vacía. RFC 8415 define el intercambio. El Rebind, la respuesta, el servidor y las opciones IA_PD son recibos posteriores, no contenido implícito en el RA.

Un registro serio conserva el origen del RA, interfaz, PIO, P/A/L, vidas y generación de la lista. En otra fila guarda si el cliente inició Solicit o Rebind y qué política local lo motivó. Un contador actual de P=1 no permite reconstruir la transición ni distinguir expiración, retirada, oscilación y pérdida de paquetes.

La respuesta puede no contener un prefijo utilizable

El cliente debe enviar una sugerencia de longitud suficientemente corta para crear direcciones mediante SLAAC. Una respuesta puede devolver un prefijo demasiado largo, que debe ignorarse. Si es más corto, el host puede aceptarlo y dividirlo en prefijos de longitud apropiada.

La P original no garantiza ninguna de esas condiciones. El servidor puede no responder, el pool puede estar agotado, la política puede rechazar al cliente o la respuesta puede llevar un estado de error. La longitud y las vidas pueden resultar inadecuadas. Tras un intento fallido y acotado, el host puede desactivar el tratamiento de P en esa interfaz y recurrir al mecanismo alternativo disponible.

Por tanto, “delegación realizada” exige enlazar la solicitud y su pista de longitud con el servidor o relay efectivo, la Reply, el IAPREFIX, sus vidas y la decisión de aceptación. La captura del anuncio demuestra que existió una invitación, no que esos hechos posteriores ocurrieron.

Tampoco P=0 es una prohibición. Un router de cliente de RFC 7084 o un host configurado localmente puede ejecutar PD sin esta señal. La ausencia no revoca una razón independiente.

El relay convierte un lease en estado de forwarding

En el modelo de RFC 9663, el servidor delega y el primer router instala una ruta al prefijo cuyo siguiente salto es la dirección link-local del cliente. Para la infraestructura, el prefijo queda off-link. Así puede mantener una ruta por dispositivo en lugar de una entrada de vecino por cada dirección global usada por el host, sus contenedores o componentes internos.

El servidor remoto no siempre controla esa ruta. RFC 8987 obliga al relay delegante a mantener bindings, next hops, rutas y filtros de ingreso en consonancia con los leases, además de ofrecer información operativa y reglas de continuidad. Una Reply vista por el cliente no demuestra que la ruta se instaló. Una ruta en un nodo no demuestra coherencia entre routers redundantes. Una RIB correcta no demuestra forwarding efectivo.

El host también debe impedir que un paquete destinado al prefijo delegado vuelva hacia la interfaz donde lo obtuvo; el prefijo es off-link allí y ese reenvío puede formar un bucle. Una ruta de descarte con métrica alta es una defensa posible. Las direcciones formadas deben asociarse a esa interfaz para la selección de origen de RFC 6724.

En multihoming conviene asociar el prefijo con la dirección link-local del servidor o relay que envió la Reply, incluso con varias direcciones cuando hay redundancia. RFC 8028 explica la relación entre prefijo de origen y router de salida. El prefijo correcto entregado al upstream equivocado sigue siendo un resultado incorrecto.

La secuencia probatoria completa queda así: RA, generación de lista P, solicitud DHCP, Reply aceptada, lease, binding, ruta, filtro, dirección, origen, primer salto, entrega y aplicación. Cada estado necesita fecha, propietario y generación. Ninguno hereda autoridad sólo por estar cerca del anterior.

El tráfico entre vecinos también cambia de recorrido

Con prefijos únicos, las direcciones de otros clientes del mismo segmento se consideran off-link. El primer paquete va al router por defecto. Un ICMPv6 Redirect puede permitir un camino directo; RFC 9762 recomienda procesarlo salvo configuración contraria. Si host o router no lo hacen, el tráfico local puede tener más latencia.

Una prueba a Internet no valida ese trayecto. Es posible que delegación y upstream funcionen mientras la comunicación entre dos clientes, el descubrimiento local o una política lateral siga una ruta inesperada. La aceptación debe cubrir direcciones y clases de tráfico distintas.

También cambia el presupuesto. RFC 9663 cambia espacio de prefijos y rutas por cliente por menos estado ND por dirección y un destino compartido para las direcciones del dispositivo. Puede ser razonable en una red inalámbrica grande y desastroso en un hogar con pocos /64 disponibles. P expresa una preferencia; no certifica que el pool ni el relay tengan capacidad.

La asignación de IANA resuelve la sintaxis, no la confianza

El registro IANA de flags del Prefix Information Option asigna el bit 3 a P y remite a RFC 9762. Eso evita dos interpretaciones del mismo bit. No autentica al emisor que aparece en un puerto concreto.

Sin las defensas de RFC 6105, un atacante local puede enviar un PIO parecido, activar P y hacer que hosts compatibles ignoren A. Si no existe PD útil, la dirección no llega o se retrasa. RFC 7113 muestra que declarar RA-Guard no prueba que fragmentos y cabeceras de extensión no permitan evasión.

DHCP conserva otra frontera. Sin DHCPv6-Shield de RFC 7610, un servidor falso puede entregar configuración inválida. Aunque router y servidor pertenezcan al mismo operador, son emisores y momentos distintos. La confianza de una RA no autentica por contagio la Reply.

Alternar P puede cambiar la lista y provocar REBIND repetidos. El rate limit de RFC 8415 reduce la emisión por cliente, pero no prueba carga nula ni continuidad. Hay que observar por separado anuncios, transiciones, transacciones y consumo de infraestructura.

La autoridad pequeña es el diseño correcto

La P no fracasa por no ser un comprobante de todo. Su alcance pequeño permite coordinar el orden sin centralizar asignación, rutas, filtros y fallback. Ésa es la lógica de la especificación inicial mínima y decisión futura localizada de Heng Lu. La primacía del código en ejecución exige comprobar qué hizo cada implementación, y sus capas de realidad separan significado normativo, paquete, lease, ruta y experiencia.

La señal funciona mejor cuando la afirmación no crece más que su autoridad.