Resumen

  • PPP tenía que entrar primero en la fase de protocolos de red e IPv6CP debía alcanzar Opened; 0x8057 identificaba el control y 0x0057 los datagramas IPv6 admitidos.
  • Dos Interface-Token diferentes resolvían la colisión dentro de ese enlace punto a punto. No autenticaban al par ni probaban unicidad mundial, titularidad, ruta o entrega.

En RFC 2023, un extremo que pedía el token cero podía recibir una sugerencia no nula en un mensaje denominado Configure-Ack. Ese detalle parece menor hasta recordar qué significa la respuesta en PPP. Ack acepta; Nak propone una alternativa; Reject saca una opción de la negociación. RFC 2472 cambiaría el caso cero a Configure-Nak. La revisión alineó el nombre del recibo con el hecho que realmente había ocurrido.

El enlace no abría IPv6 por sí solo

RFC 1661 ordenaba PPP por fases. LCP establecía, configuraba y probaba el enlace de datos. Podía seguir una autenticación. Después comenzaba la fase de protocolos de red, donde cada protocolo de capa de red era configurado por su propio NCP.

RFC 2023 definió IPv6CP para IPv6. Los paquetes del protocolo de control llevaban 8057 y no podían intercambiarse antes de la fase de red. Los datagramas IPv6 llevaban 0057 y solo podían comunicarse después de que IPv6CP estuviera Opened.

Así aparecen tres recibos distintos. LCP Opened habla del enlace de datos. La fase de red permite iniciar la configuración específica. IPv6CP Opened autoriza el tipo de paquete. Ninguno afirma que exista una ruta, que se haya enviado un datagrama o que una aplicación lo haya recibido.

La comparación era bilateral

Interface-Token era la opción tipo 1, de seis octetos, con un valor de 32 bits. Cada extremo elegía un candidato. La recomendación era construir un valor no nulo con varias fuentes de diferencia; una sola dirección de enlace podía no ser única. Si no había una buena fuente, el cero permitía solicitar ayuda al par.

El receptor comparaba el token recibido con el de su última Configure-Request. Valores no nulos y diferentes podían confirmarse. Si eran iguales, había una colisión local y debía enviarse Configure-Nak con otro valor. Dos ceros terminaban la negociación mediante Configure-Reject, sin valor predeterminado y sin una recuperación especificada.

También podía ocurrir que ambos extremos cruzaran la misma sugerencia. Si la propuesta recibida en un Nak coincidía con la última que el receptor había enviado al par, debía escoger un candidato nuevo. Si no coincidía, podía incorporarla a una nueva solicitud. No existía un registro central: la diferencia surgía de rondas que hacían visible el choque.

Lo que cada respuesta no decía

Un Ack de un token no nulo registra aceptación de una solicitud concreta en una dirección. No completa automáticamente la dirección opuesta. Tampoco autentica a nadie. RFC 2023 dejó las cuestiones de seguridad sin desarrollar, por lo que el token no puede ascender a credencial.

Un Nak registra desacuerdo y una propuesta. No demuestra que el solicitante la haya usado, que haya llegado un Ack posterior o que IPv6CP esté abierto. Un Reject registra que esa opción ya no sigue en la negociación. Puede indicar falta de soporte o el fracaso del caso cero contra cero; no prueba un reemplazo manual exitoso.

El alcance de la palabra «único» era igualmente exacto: dentro del enlace PPP. Dos valores distintos separaban los dos extremos de esa instancia. No eran asignaciones globales, nombres permanentes ni certificados de una persona, equipo u organización. No demostraban autorización para utilizar el enlace ni propiedad de la dirección formada con el token.

Una capacidad negociada tampoco era uso

La segunda opción de IPv6CP describía la capacidad de recibir un protocolo específico de compresión IPv6. Cada sentido debía solicitarla por separado si se quería compresión bidireccional; el valor por defecto era no comprimir. La aceptación de la opción no es un paquete comprimido, y un paquete no prueba descompresión ni entrega.

Esa separación ayuda a leer Opened. El estado resume que el intercambio de configuración llegó al punto de admitir IPv6. No resume todo lo que puede pasar después. Política de ruta, reenvío, recepción remota, integridad, transporte y aplicación siguen teniendo propietarios y pruebas diferentes.

RFC 2023 quedó obsoleta por RFC 2472, que amplió el valor a un Interface-Identifier de 64 bits y corrigió la respuesta al cero. RFC 5072 reemplazó después a RFC 2472. El registro IANA actual mantiene 0057 e 8057, pero cita RFC 5072. La pieza de 1996 es un fósil de diseño útil precisamente porque permite ver qué cambió.

Observar una trama 0057 solo acredita que un paquete fue clasificado como IPv6 en ese punto. Para afirmar entrega hacen falta observaciones correlacionadas al otro lado, controles de integridad y alguna respuesta de transporte o aplicación. Para afirmar identidad o autorización hacen falta credenciales y decisiones de acceso. La negociación de tokens no contiene ninguna de esas pruebas.

La lección histórica es una de alcance. IPv6CP podía convertir una colisión visible en otra ronda y terminar con dos valores locales diferentes. Había resuelto un problema necesario, no todos los problemas que rodean al paquete. Confundir esa modestia con una prueba universal es perder justamente la arquitectura que PPP hizo explícita.

Fuentes