Resumen

  • Que IPV6CP llegue a Opened demuestra una transición concreta del plano de control de PPP; no demuestra que exista una dirección global utilizable.
  • Si se omite DAD para esa dirección, la organización debe demostrar y conservar dos condiciones de topología que no están incluidas en el acuse de IPV6CP.

El usuario avisa de que IPv6 no funciona. La mesa de acceso responde con una captura: LCP completado, IPV6CP abierto, identificador aceptado. Para el sistema de tickets, el servicio ya está entregado.

La captura responde a otra pregunta.

RFC 5072 establece que PPP debe entrar en la fase de protocolo de red y que IPV6CP debe alcanzar Opened antes de comunicar paquetes IPv6. Esa secuencia protege el orden del enlace. No afirma que el abonado tenga una dirección global, que esa dirección sea única, que exista una ruta o que un destino haya contestado.

La única opción de IPV6CP definida en el documento negocia un Interface-Identifier de 64 bits. Cada extremo propone una sola instancia. Si las propuestas no nulas son diferentes, pueden recibir Configure-Ack. Si coinciden, se responde con Configure-Nak y una alternativa. Si ambas son cero, la negociación termina con Configure-Reject. El resultado prueba diferenciación dentro de ese enlace punto a punto.

El mecanismo tampoco esconde el fallo detrás de un valor implícito. Sin un identificador válido no hay valor predeterminado; el procedimiento de recuperación queda sin especificar y la configuración manual aparece como una posibilidad. Por eso un reinicio automático, un valor generado por la plataforma o una intervención del operador deben quedar registrados por separado.

El identificador acordado sirve para formar la dirección de enlace local. RFC 5072 advierte que no debe suponerse que también compondrá la dirección unicast global. El extremo puede generar uno o varios identificadores distintos. La negociación local y la dirección global pertenecen, por diseño, a recibos diferentes.

La diferencia se vuelve operativa al decidir sobre Duplicate Address Detection. Para la dirección de enlace local, comprobar un duplicado resulta redundante cuando IPV6CP ya separó los valores de ambos extremos. Para una dirección global, el RFC permite considerar redundante DAD únicamente si se cumplen dos condiciones a la vez.

El prefijo anunciado por el router debe ser exclusivo de esa conexión PPP. Además, el propio router terminador no debe autoconfigurarse una dirección global a partir de ese prefijo. Solo bajo esas premisas el documento recomienda que la administración configure DupAddrDetectTransmits en cero.

Un cero no es un DAD positivo. Es la ausencia deliberada del ensayo. La organización sustituye observación de paquetes por confianza en el aprovisionamiento del prefijo y en la configuración del router. Cuando una automatización reutiliza un prefijo o incorpora una dirección al terminador, el antiguo Configure-Ack sigue existiendo aunque la justificación haya desaparecido.

RFC 4862 parte de otra regla: toda dirección unicast debe pasar DAD antes de asignarse, provenga de SLAAC, DHCPv6 o configuración manual, salvo excepciones expresas. También define que cero transmisiones significa que DAD no se ejecuta. El control alternativo debe poder auditarse con la misma seriedad.

La obtención global añade una bifurcación. En la vía sin estado, el host combina un prefijo anunciado con un identificador. En la vía con estado, obtiene la dirección de un servidor como DHCPv6. Un anuncio de router no es un arrendamiento; un arrendamiento no es instalación; instalación no es encaminamiento; encaminamiento no es respuesta remota.

La recomendación sobre identificadores cambió después. RFC 8064 actualiza formalmente RFC 5072, favorece el esquema opaco de RFC 7217 para direcciones SLAAC estables y desaconseja incrustar direcciones estables de capa de enlace. Saber qué edición normativa existe no revela qué algoritmo ejecutó el equipo durante el incidente.

Tampoco hay que confundir la apertura con la identidad del extremo. RFC 5072 trata listas de control, autenticación y cifrado como mecanismos separados. Incluso señala el riesgo de repetición de un método basado en MD5. Un plano IPv6 abierto puede coexistir con una autenticación insuficiente o una política de admisión equivocada.

Una prueba útil de entrega conserva la secuencia completa: estado LCP; resultado de autenticación y autorización; mensajes IPV6CP y valores propuestos; Ack, Nak o Reject; dirección de enlace local; rama de obtención global; prefijo, identificador y vigencias; DAD real o prueba de ambas condiciones de excepción; dirección y ruta instaladas; origen observado en un paquete; respuesta del par; resultado de la aplicación.

No es una ampliación secreta del RFC, sino disciplina operativa inspirada en las capas de realidad de Heng Lu. Una intención, una negociación, una configuración, una transmisión y un resultado pueden relacionarse. No deben colapsarse en una sola luz verde.

Sources