Resumen

  • Un PvD es un límite de coherencia para direcciones de origen, DNS, routers y demás configuración. El FQDN, los indicadores H/L/R y la secuencia identifican y renuevan ese límite, pero no ordenan las rutas disponibles.
  • La confianza se arma por etapas: la información adicional se obtiene dentro del mismo PvD, se autentica el nombre y se validan identificador, caducidad y prefijos. Solo después la política local decide, y la conexión revela qué origen, resolvedor y siguiente salto fueron usados.

El nombre conocido no ganó la conexión

Un host recibe dos PvD explícitos en un solo enlace. El primero lleva el FQDN de un operador conocido, anuncia información adicional con el indicador H y muestra una secuencia posterior a la observada el día anterior. Un panel de operaciones lo resalta y lo declara seleccionado.

El objeto JSON autenticado para ese dominio contiene noInternet: true. No está averiado: ofrece correctamente servicios restringidos. El segundo PvD es el único apropiado para una conexión a Internet abierta, y la política del host lo escoge para el navegador.

La discrepancia está en el panel. La identidad del dominio, la frescura de sus datos, su aptitud para una finalidad y la elección ejecutada son hechos distintos. Una secuencia nueva puede refrescar un servicio local sin convertirlo en salida general.

Esta distinción responde a un problema antiguo del multihoming. Un host puede combinar una dirección obtenida en una red, un DNS de otra y el router por defecto de una tercera. Cada dato parece legítimo; el conjunto produce una ruta incoherente. RFC 7556 creó el concepto de Provisioning Domain, o PvD, para que la procedencia sobreviva a la selección.

El dominio no equivale a una interfaz

RFC 7556 define un PvD como un conjunto coherente de información de configuración de red. Puede incluir prefijos de origen, servidores DNS, sufijos de búsqueda, proxies y gateways predeterminados.

En un mismo enlace pueden coexistir varios PvD, y un solo PvD puede extenderse por varios enlaces. Por eso no basta con cambiar el nombre de la interfaz por el del dominio. La frontera expresa qué parámetros forman una unidad operativa, no en qué conector físico aparecieron.

La arquitectura contempla PvD implícitos, deducidos de la fuente de configuración, y explícitos, marcados con una identidad. Un host consciente de esos dominios mantiene cada parámetro asociado con su origen. Al abrir una conexión, el sistema, el usuario o la aplicación eligen un PvD según su política y usan dentro de él una dirección, un DNS y un siguiente salto compatibles.

No existe una clasificación universal. Seguridad, precio, alcance, disponibilidad y preferencia pueden producir elecciones distintas. Una aplicación empresarial puede utilizar un dominio restringido mientras el navegador usa, en el mismo equipo, uno de acceso público. El PvD organiza alternativas; no proclama un ganador para toda la máquina.

El Router Advertisement propone el contexto

RFC 8801 define la opción PvD como tipo 21 de Neighbor Discovery dentro de un Router Advertisement IPv6. La opción lleva un identificador en forma de FQDN, indicadores H/L/R, una secuencia de 16 bits, un campo Delay y, cuando corresponde, información RA interna.

Quien anuncia el ID debe poseer y administrar ese FQDN. El mismo nombre solo debería utilizarse cuando el servicio final sea realmente idéntico; servicios diferentes requieren identificadores distintos. Esa regla concede al operador un espacio de nombres estable sin afirmar que el nombre autentique por sí solo al router local.

Los indicadores tienen potestades limitadas. H anuncia que existe información adicional por HTTPS. L vincula información heredada de DHCPv4. R indica una cabecera RA y opciones internas para hosts compatibles. H no demuestra que la descarga ocurrió ni que el objeto fue aceptado. R no expresa preferencia. L tampoco autoriza a mezclar cualquier dato DHCP con el dominio.

La secuencia controla generaciones de información dentro de un mismo PvD. Un cambio invalida el objeto anterior y puede provocar una recuperación con espera aleatoria. No es una puntuación: 42 en un dominio no supera a 7 en otro. Delay distribuye la carga de consulta; no mide urgencia ni calidad.

La información debe volver por su propio PvD

Con H activado, el host puede consultar https://<PvD-ID>/.well-known/pvd. Sin H, no debe utilizar este mecanismo. La respuesta se identifica como application/pvd+json.

La regla más exigente afecta al recorrido de esa petición. La resolución DNS del ID, las comprobaciones del certificado, la conexión HTTPS, la dirección de origen y el siguiente salto deben usar exclusivamente la configuración del PvD examinado. Preguntar el nombre en una segunda red y descargarlo por una tercera destruye la vinculación que se intentaba verificar.

La separación también protege la privacidad. Un DNS dividido puede devolver respuestas diferentes por contexto. El prefijo de origen condiciona el primer router y el retorno. Consultar en otra red un FQDN propio de una empresa revela que el dispositivo ha visto ese entorno. Registrar solo la URL final no permite reconstruir la prueba.

El certificado TLS debe contener un DNS-ID idéntico al PvD ID. Si falla, el host cierra la conexión y trata al PvD como si no tuviera información adicional. Esto demuestra que el titular del FQDN autoriza el servicio HTTPS para ese nombre; no acredita por sí mismo el anuncio local ni todos los prefijos reclamados.

El objeto autentica una relación más estrecha

Un JSON válido incluye identifier, expires y prefixes. El identificador coincide con el ID anunciado, la fecha está en el futuro y los prefijos cubren todas las Prefix Information Options de la RA asociada. La ausencia o invalidez de un campo obligatorio obliga a ignorar el objeto; un prefijo sin cobertura constituye una configuración errónea que no debe utilizarse.

Así se cotejan dos afirmaciones. El router local dice que una configuración pertenece a un nombre. El servicio autenticado dice que ese nombre reconoce unos prefijos. El control de una sola superficie no basta para fabricar toda la relación.

Las claves opcionales no cambian esta distribución de autoridad. dnsZones describe zonas utilizables en el PvD. noInternet: true indica una red restringida, no una red rota. Para una fábrica, un hospital o una empresa, la ausencia deliberada de Internet abierto puede ser la propiedad buscada.

Las claves desconocidas se ignoran para permitir evolución. IANA administra el registro compartido; los experimentos privados se alojan en subdiccionarios organizativos o vendor-*. Estar registrado aporta semántica común, no veracidad a un anuncio ni despliegue universal.

La frescura no es una autoridad eterna

Cuando cambia la secuencia o llega la fecha de expiración, la información almacenada queda obsoleta. Delay y la aleatoriedad de la actualización evitan que miles de hosts consulten a la vez. El tiempo absoluto puede estar desviado, por lo que la caducidad no debe convertirse en fundamento único de una decisión sensible de seguridad.

La recuperación puede ser explotada por un router malicioso para provocar DNS, TLS y HTTP hacia numerosos servidores. El host limita la frecuencia, deja de consultar un ID después de un fallo de certificado, HTTP o JSON durante esa conexión a la red, y tras diez fallos o más deja de pedir información para todos los PvD del enlace actual.

El operador que activa H asume a su vez una obligación. Incluso un portal cautivo debe permitir antes del inicio de sesión el DNS, la validación del certificado y el HTTPS necesarios. El host debería emplear una dirección IPv6 temporal del PvD y evitar cookies o cabeceras identificables; una consulta opcional no debe transformarse en una baliza persistente.

La selección pertenece al host

Con los dominios validados, todavía falta una decisión para cada conexión. El operador puede nombrar y aprovisionar un contexto. El dueño del FQDN autoriza el servicio de datos. El JSON delimita propiedades. El host decide qué conjunto satisface la aplicación presente.

La prueba está en el código en ejecución: dirección de origen, servidor DNS, primer router, destino y resultado. Running-Code Primacy no sustituye los requisitos comunes; exige comprobar que la implementación mantuvo las asociaciones mínimas que hacen posible la interoperabilidad.

Fuentes