Résumé

  • RFC 3361 attribuait à l’option DHCPv4 120 deux encodages exclusifs : une liste privilégiée de noms DNS ou une liste ordonnée d’adresses IPv4 désignant des proxys SIP sortants locaux.
  • Le nom pouvait déléguer au DNS le choix du transport, du port, de l’instance et du repli ; l’adresse figeait un ordre d’hôtes. Aucun des deux ne démontrait que la transaction SIP ou le chemin d’appel aboutirait.

Un paramètre de configuration paraît souvent plus complet qu’il ne l’est. Il arrive tôt, avant que l’application n’agisse, et porte l’autorité du serveur qui équipe le poste. En 2002, un client SIP pouvait ainsi recevoir par DHCP l’endroit où envoyer ses requêtes sortantes. Le bail répondait à la première question. Il ne répondait pas aux suivantes.

RFC 3361, publiée sur le Standards Track en août 2002, définit l’option DHCPv4 120 pour découvrir un proxy SIP sortant local. Un client pouvait parfois joindre directement la destination d’un URI SIP. Dans d’autres environnements, notamment lorsqu’un pare-feu intervenait, il devait passer par un serveur local. DHCP restait une méthode parmi plusieurs, à côté de la configuration manuelle.

La structure portait un choix décisif juste après le code et la longueur. La valeur zéro de l’octet enc annonçait une suite de noms de domaine. La valeur un annonçait une ou plusieurs adresses IPv4 binaires. Toute implémentation devait comprendre les deux formes, même si le texte recommandait la forme DNS.

Ces formes ne véhiculaient pas seulement le même renseignement sous deux apparences. Un nom ouvrait la procédure de localisation de RFC 3263. Les enregistrements NAPTR pouvaient annoncer les transports, les enregistrements SRV les instances, ports, priorités et poids, puis A ou AAAA fournir les adresses. Le client retirait les transports qu’il ne savait pas utiliser et appliquait sa politique. Le nom déléguait donc le prochain choix à un graphe de service modifiable.

La liste IPv4 disait moins, mais de façon plus directe. Les hôtes étaient placés par ordre de préférence. L’option n’emportait ni service NAPTR, ni port SRV, ni priorité, ni poids, ni description du transport. Elle fixait une séquence de candidats dans le bail, là où le nom laissait une autre administration faire évoluer le service.

La différence répartissait l’autorité. Avec un domaine, l’administrateur DNS pouvait déplacer un service, modifier une préférence ou annoncer un transport sans renouveler le bail DHCP. Avec des adresses littérales, l’administrateur DHCP conservait davantage du choix dans l’option. Dans les deux cas, le logiciel du client, son cache, sa politique et l’état du réseau restaient capables de contredire l’intention.

RFC 3361 donnait aussi un sens précis à plusieurs noms. Ils devaient plutôt pointer vers des domaines NAPTR distincts, par exemple des fournisseurs différents, que remplacer plusieurs enregistrements A d’un même domaine. Le client essayait les domaines dans l’ordre. Il ne passait au suivant qu’en cas d’échec de contact, d’absence de transport commun ou d’interdiction administrative locale.

Plusieurs ordres s’emboîtaient alors sans se confondre. DHCP ordonnait les domaines de fournisseurs. NAPTR organisait les services de transport. SRV répartissait les instances par priorité et par poids. La résolution donnait des adresses. La capacité et la politique du client filtraient le résultat. Dire simplement « le proxy configuré » effaçait les décideurs successifs.

RFC 3263 imposait ensuite une frontière transactionnelle. Dès qu’un serveur avait été contacté avec succès pour une transaction SIP, les retransmissions, le CANCEL et l’ACK d’une réponse finale non 2xx devaient viser le même serveur. Le DNS pouvait aider à choisir avant l’établissement de cet état ; il ne devait pas redistribuer au hasard les messages appartenant déjà à la transaction.

Le format de l’option révélait une autre frontière. Un serveur DHCP ne devait jamais mélanger noms et adresses dans le même message, même à travers deux occurrences distinctes de l’option 120. Les règles DHCP concatènent les occurrences répétées avant d’en interpréter le contenu. Deux fragments valides selon des grammaires différentes deviendraient un seul objet incohérent.

RFC 3396 formalisa quelques mois plus tard l’ordre de concaténation des options DHCPv4 répétées. Elle permit de répartir une valeur longue sur plusieurs occurrences et champs surchargés. Mais elle nota également que de nombreux agents déployés ne savaient pas reconstituer ces options. Une liste de domaines trop longue pouvait donc être encodée conformément à la norme et rester illisible pour le client réel.

RFC 3361 exigeait précisément l’usage de ce mécanisme au-delà de la capacité d’une occurrence. Avant toute requête DNS, le système dépendait déjà de l’ordre des fragments et de la compatibilité du décodeur. La preuve d’émission du serveur n’était pas la preuve d’une interprétation identique par le client.

L’année suivante, RFC 3319 modifia le dessin pour DHCPv6. Elle créa deux codes d’option distincts, l’un pour les noms, l’autre pour les adresses IPv6. Le texte expliquait que DHCPv6 ne manquait pas de codes et pouvait donc supprimer l’octet d’encodage. Les options séparées étaient plus courtes, plus simples à analyser, mieux alignées pour les nombres et pouvaient être demandées séparément. Une rareté dans le registre DHCPv4 avait produit de la complexité dans chaque message.

Le choix du nom avait lui aussi une histoire. RFC 3361 reprenait l’encodage par étiquettes de RFC 1035 et exigeait la compression DNS, notamment pour rester compatible avec de futurs mécanismes de noms internationalisés. En dessous, SRV venait de RFC 2782 et NAPTR de la famille formalisée par RFC 3403. Une petite option pouvait rester petite parce qu’elle pointait vers des mécanismes plus vastes.

L’indirection étendait simultanément la flexibilité et la confiance. La section de sécurité de RFC 3361 avertissait qu’une réponse DHCP modifiée ou injectée pouvait envoyer l’agent utilisateur vers un proxy SIP hostile, permettre une interception ou provoquer un déni de service. Elle pouvait aussi supprimer les noms menant à des serveurs SIP utilisant TLS. La couche de configuration ne transportait pas la conversation, mais choisissait la première porte de sa signalisation.

Le registre IANA actuel des paramètres BOOTP et DHCP conserve le code 120. Ce fait prouve la coordination du numéro et de son nom. Il ne prouve pas qu’un réseau le diffuse aujourd’hui, qu’un client le demande, qu’une pile comprend les deux formes ni qu’un proxy indiqué fonctionne.

Le bail observé doit être lu avec la même retenue. Une capture prouve la présence de certains octets. Un décodeur peut établir qu’ils représentent des domaines ou des adresses. Il faut encore prouver la résolution, l’intersection des transports, l’ouverture de la connexion, la réponse du proxy, la localisation des sauts suivants, la négociation de session et le passage du média.

Chaque couche demande son reçu. Il faut conserver le serveur et le relais DHCP, les octets bruts, la forme d’encodage et l’ordre. Pour un nom, conserver NAPTR, SRV, A et AAAA avec leurs TTL et le choix filtré. Pour une adresse, conserver l’ordre des tentatives, le port et le transport. Puis séparer le contact du proxy, la transaction SIP, le routage suivant, la description de session et le média.

Deux textes de Lu Heng servent ici de perspectives déclarées. « Minimum Initial Specification » éclaire la valeur d’un mécanisme commun étroit qui laisse aux opérateurs le choix du fournisseur, du DNS et du déploiement. « Reality Layers » empêche de confondre code enregistré, configuration reçue, service résolu, implémentation active et résultat d’appel. Il s’agit de lectures éditoriales, non d’affirmations sur l’auteur ou l’intention de RFC 3361.

L’option 120 créait un rendez-vous, pas une arrivée. Son octet d’encodage pouvait confier les décisions suivantes à un système de noms vivant ou les enfermer dans une file d’adresses. Le bail indiquait où commencer la signalisation ; la suite appartenait encore au monde des preuves.

Sources