Résumé

  • RFC 1877 ajoutait à IPCP quatre options pour les adresses DNS et NBNS primaires et secondaires ; une adresse nulle demandait explicitement au pair de faire une proposition dans Configure-Nak.
  • Le Nak était un conseil, pas une acceptation : le client devait reformuler sa demande, obtenir un Configure-Ack correspondant, puis atteindre l’état IPCP Opened.
  • L’adresse convenue n’était qu’un point de départ. Route, requête, réponse, autorité de la donnée et usage par l’application exigeaient chacun leur propre trace.

Le refus transportait l’information utile

La scène est celle d’un modem qui vient d’établir une liaison. L’hôte sait transporter IP, mais il ne sait pas encore où poser une question DNS. RFC 1877, publié comme document informatif en décembre 1995, proposait une réponse étonnamment économique : utiliser le mécanisme de négociation d’IPCP déjà présent au lieu d’inventer un service séparé.

Quatre numéros furent définis. Le type 129 désignait le serveur DNS primaire, 130 le serveur NBNS primaire, 131 le serveur DNS secondaire et 132 le serveur NBNS secondaire. Chaque option avait la même forme : un type, une longueur de six octets et une adresse IPv4 de quatre octets. Le registre PPP de l’IANA conserve encore ces quatre attributions. Il atteste la signification des nombres, non leur utilisation actuelle.

Le texte source exige toutefois une lecture attentive. Dans la section 1.3, une phrase isolée de la description du champ nomme un serveur NBNS primaire, alors que le titre de la section, son schéma et l’attribution du type 131 indiquent tous un DNS secondaire. Cette discordance est une limite documentaire, pas une raison de promouvoir la phrase errante en sémantique du protocole.

Pour demander une adresse, l’extrémité locale pouvait envoyer zéro. Les quatre octets nuls signifiaient explicitement : fournissez l’information dans un Configure-Nak. Le client pouvait aussi présenter une autre valeur volontairement invalide. Le pair refusait cette valeur et retournait celle qu’il jugeait acceptable.

Ce refus n’était donc ni une panne ni une installation silencieuse. Il disait : « cette proposition ne convient pas ; voici une valeur que j’accepterais ». La nuance empêchait le destinataire de la réponse de perdre son pouvoir de décision.

Entre la proposition et l’accord, il restait un paquet

RFC 1332 avait défini IPCP, le protocole de contrôle IP de PPP. RFC 1877 reprit délibérément le format et le comportement de son option IP-Address. Les messages avaient des fonctions distinctes : Configure-Nak proposait une autre valeur, tandis que Configure-Reject renvoyait sans modification une option non reconnue ou non négociable. Configure-Ack, lui, acceptait exactement la demande courante.

Imaginons une demande de type 129 contenant 0.0.0.0. Le pair renvoie un Nak avec 192.0.2.53. La capture prouve que le pair a compris l’option et proposé cette adresse. Elle ne prouve pas que le client l’a adoptée. Celui-ci doit émettre une nouvelle Configure-Request avec 192.0.2.53. Un Ack correspondant exactement à cette dernière demande établit alors l’accord.

Une console qui transforme immédiatement le Nak en « DNS configuré » attribue au pair une autorité qu’il n’avait pas. À l’inverse, conserver l’Ack sans la requête associée retire l’objet même du consentement. Identifiant de paquet, tentative, valeur et ordre sont nécessaires pour distinguer un accord courant d’une réponse ancienne ou dupliquée.

RFC 1661 place encore cette séquence dans une architecture plus large. La couche physique devient disponible ; LCP établit la liaison ; une authentification éventuelle se termine ; puis vient la phase des protocoles réseau. Chaque protocole réseau y est configuré par son NCP. IPCP doit atteindre Opened avant que le trafic IP correspondant soit admis.

Ainsi, un Ack d’option DNS n’est pas un certificat d’ouverture. Une ouverture IPCP n’est pas un certificat de route. Et une route n’est pas une réponse DNS.

DNS et NBNS partageaient un moule, pas une autorité

La symétrie des quatre options cachait deux services différents. Le DNS de RFC 1034 et RFC 1035 organise des résolveurs, des serveurs et une autorité distribuée sur les domaines. Le service de noms NetBIOS décrit par RFC 1001 et RFC 1002 possède ses propres rôles et échanges. Une représentation IPCP commune facilitait le code ; elle ne rendait pas les réponses substituables.

Les adresses primaire et secondaire étaient négociées séparément. Lorsque les deux existaient, RFC 1877 recommandait d’essayer la primaire avant la secondaire. Ici, « primaire » exprime un ordre d’usage par le client. Il ne signifie pas que ce serveur détient la copie maîtresse d’une zone DNS. Importer ce second sens dans le premier produirait une fausse preuve d’autorité.

La négociation pouvait aussi être partielle. Le pair pouvait accepter le DNS primaire mais pas le secondaire, fournir DNS sans NBNS, ou proposer des valeurs pendant deux tentatives différentes. Aucune règle ne transformait les quatre options en transaction atomique. L’absence avait même une sémantique claire : par défaut, aucune adresse n’était fournie.

Une bonne adresse pouvait être inutile au mauvais endroit

RFC 1877 déconseillait d’ajouter ces options à la liste recommandée d’IPCP. Leur utilité dépendait de la topologie du réseau distant et de l’application locale. Cette réserve est le centre opérationnel du texte. Une adresse syntaxiquement correcte, comprise et acceptée peut rester hors de portée depuis l’interface réellement ouverte. Elle peut répondre à DNS alors que l’application attend NBNS, ou être joignable tout en servant une donnée que la politique locale refuse.

La chaîne de preuve doit donc continuer après la négociation : IPCP Opened, installation de l’interface et de la route, paquet envoyé, serveur atteint, requête corrélée, réponse reçue, autorité ou intégrité évaluée, réponse choisie par l’application, résultat rendu à l’utilisateur. Chaque étage a son producteur et peut échouer seul.

Le document ne discutait pas les questions de sécurité. Ce silence ne constitue pas une propriété de sûreté. RFC 1877 n’authentifiait ni le pair qui proposait l’adresse, ni le serveur visé, ni les données retournées plus tard. Son statut informatif ne prouve pas davantage une adoption universelle.

L’innovation tenait à une frontière bien gardée. PPP pouvait obtenir un renseignement de configuration sans le faire passer pour un résultat. L’adresse convenue disait où essayer. Le réseau et le service devaient encore répondre.