Resumen

  • RFC 1877 añadió cuatro opciones IPCP para obtener DNS y NBNS primarios y secundarios; los cuatro octetos a cero pedían expresamente una propuesta en Configure-Nak.
  • El Nak no aceptaba ni reescribía la solicitud. El cliente tenía que presentar el valor propuesto en otra Configure-Request y recibir el Ack correspondiente.
  • Incluso con IPCP abierto, la dirección acordada no probaba ruta, respuesta ni nombre correcto. El servicio y la aplicación debían producir sus propias evidencias.

Pedir algo mediante un valor imposible

Un host acababa de llamar, negociar el enlace y obtener capacidad para transportar IP. Sin embargo, escribir un nombre podía fallar porque el sistema no sabía a qué servidor preguntarle. RFC 1877 trató ese problema en diciembre de 1995 sin crear un protocolo nuevo: añadió la información a IPCP, el protocolo que ya configuraba IP sobre PPP.

Las opciones 129 y 131 llevaban las direcciones DNS primaria y secundaria. Las 130 y 132 hacían lo mismo para NBNS. Todas tenían seis octetos: tipo, longitud y una dirección IPv4. El registro PPP de IANA mantiene hoy esos números. Esa continuidad demuestra asignación, no implementación ni uso actual.

El propio texto requiere cautela. En la sección 1.3, una frase aislada de la descripción del campo habla de un NBNS primario, pero el título de la sección, el diagrama y la asignación del tipo 131 señalan un DNS secundario. La contradicción limita la limpieza de la fuente; no autoriza a convertir esa frase suelta en semántica del protocolo.

La forma de preguntar parecía paradójica. El extremo local incluía una dirección que esperaba que fuera inválida. Si ponía 0.0.0.0, declaraba de manera explícita que quería recibir la información en un Configure-Nak. El remoto rechazaba el valor y colocaba en el Nak una dirección que consideraba válida.

El rechazo preservaba dos decisiones. El remoto podía decir qué aceptaría; el local seguía decidiendo si quería volver a pedirlo. Convertir esa respuesta negativa directamente en configuración habría mezclado consejo con consentimiento.

El acuerdo estaba en la segunda petición

RFC 1877 copió el formato y la conducta de la opción IP-Address de RFC 1332. La secuencia importaba. Configure-Request formulaba una propuesta; Configure-Nak devolvía un valor alternativo. Configure-Reject devolvía sin cambios una opción que el par no reconocía o no podía negociar. Configure-Ack aceptaba exactamente la solicitud vigente.

Si el cliente enviaba el tipo 129 con cero y recibía 192.0.2.53 en un Nak, la captura demostraba que el otro extremo entendió la opción y ofreció ese valor. No demostraba que el cliente lo hubiera instalado. El cliente debía remitir otra Configure-Request con 192.0.2.53. Solo el Ack de esa petición cerraba el acuerdo sobre la dirección.

Por eso un registro serio conserva el identificador, el intento y ambos paquetes. Un Nak antiguo puede llegar tarde; una respuesta puede duplicarse; una nueva solicitud puede contener otros valores. Guardar únicamente «servidor DNS = 192.0.2.53» borra quién lo propuso, quién lo aceptó y para qué sesión.

RFC 1661 añade más escalones. Primero existe el medio físico. Después LCP establece el enlace y puede seguir una autenticación. Luego PPP entra en la fase de protocolos de red. Cada NCP se abre por separado, e IP solo debe circular cuando IPCP alcanza Opened. Un Ack de una opción puede existir antes de esa transición; por sí solo no abre el camino.

Cuatro opciones no formaban una sola transacción

DNS y NBNS compartían el molde IPCP, pero no el servicio. RFC 1034 y RFC 1035 describen el sistema de nombres de dominio y el intercambio entre resolutores y servidores. RFC 1001 y RFC 1002 definen el servicio de nombres NetBIOS sobre TCP/UDP. La igualdad de longitud no convertía una respuesta en la otra.

Primaria y secundaria se negociaban de modo independiente. Si ambas estaban disponibles, RFC 1877 recomendaba intentar primero la primaria. Era una prioridad de uso para el cliente PPP, no una afirmación sobre qué servidor era maestro de una zona DNS. El mismo adjetivo pertenecía a otra capa y no transfería autoridad.

También era posible obtener solo una parte: DNS primario sin secundario, DNS sin NBNS o valores propuestos en rondas distintas. No había una confirmación atómica de los cuatro campos. Cada uno tenía además el mismo estado por defecto: no se proporcionaba ninguna dirección. La omisión no autorizaba inventar una heredada.

La topología podía desmentir una negociación correcta

El propio RFC aconsejaba no incluir estas opciones en la lista recomendada de IPCP. Su utilidad dependía de la topología de la red remota y de la aplicación local. Una dirección podía ser válida para el par y, sin embargo, quedar fuera de la ruta instalada para el cliente. El servidor podía responder a DNS mientras la aplicación buscaba NBNS. Podía devolver una respuesta sintácticamente correcta que la política local no aceptara.

La dirección negociada era, por tanto, una coordenada inicial. Después hacían falta pruebas separadas de IPCP Opened, interfaz y ruta, paquete emitido, consulta recibida, respuesta correlacionada, autoridad o integridad, elección primaria/secundaria y consumo por la aplicación. Una interfaz «conectada» no resumía esas decisiones.

RFC 1877 era Informativo, no un estándar de Internet, y declaró que no discutía cuestiones de seguridad. El primer hecho limita lo que puede afirmarse sobre obligación y despliegue. El segundo no es una garantía: el mecanismo no autenticaba al par, al servidor propuesto ni las respuestas posteriores.

Su valor histórico está en haber transportado configuración sin prometer el resultado. La negociación contestaba «¿qué dirección aceptamos para esta sesión?». La resolución de nombres seguía siendo otra pregunta.