Résumé

  • RFC 3319 définit deux options DHCPv6 pour trouver des proxies SIP sortants locaux : une liste ordonnée de noms de domaine et une liste ordonnée d’adresses IPv6.
  • Si les deux sont reçues, le client devrait privilégier les noms et appliquer les règles de localisation SIP ; ces options proposent des destinations, elles ne certifient ni le proxy ni l’aboutissement d’un appel.

Le besoin d’un intermédiaire n’était pas celui d’un appel réussi

Le problème de RFC 3319 se résume facilement de travers. Un client peut connaître l’adresse inscrite dans un URI SIP et avoir malgré tout besoin d’un proxy sortant local. Un pare-feu, un plan de numérotation ou des services locaux peuvent justifier cet intermédiaire. La configuration manuelle constituait déjà une solution ; RFC 3319 en propose une autre : DHCPv6 peut fournir les candidats à essayer.

Le choix du mot « proxy » est important. Le serveur visé ici est l’hôte qui exécute un proxy SIP sortant, non l’ensemble du service téléphonique. RFC 3261 distingue agents utilisateurs, proxys, serveurs de redirection et registrars. Une adresse de proxy dans une réponse DHCP ne montre pas qu’un utilisateur est enregistré, que la destination est autorisée, qu’un dialogue SIP est achevé ou que les médias circulent.

Deux formats, mais un ordre de préférence

Le code 21, OPTION_SIP_SERVER_D, transporte une liste de noms de domaine ; le code 22, OPTION_SIP_SERVER_A, une liste d’adresses IPv6. Les deux sont classés par préférence. Une implémentation conforme doit prendre en charge les deux. Le client peut demander l’un ou les deux dans l’Option Request Option DHCPv6. Le serveur répond selon sa configuration et la demande : même sollicité sur les deux formats, il peut n’en envoyer qu’un et devrait privilégier la liste de noms.

Lorsque les deux listes arrivent, le client devrait commencer par les noms. La liste d’adresses numériques constitue un recours conditionnel : il peut y passer seulement si aucun nom de la première liste ne peut être résolu ou atteint. Et il ne résout pas d’emblée tous les noms suivants. Il suit l’ordre fourni ; il ne passe au suivant que si la tentative précédente échoue, ne trouve aucun transport commun ou si une règle locale interdit le domaine.

Un nom nourrit la localisation SIP, il ne la remplace pas

Les noms sont traités selon la méthode de localisation des serveurs SIP de RFC 3263. Ils devraient renvoyer à des enregistrements NAPTR distincts plutôt qu’à de simples enregistrements A distincts. RFC 3319 indique que plusieurs noms permettent à un seul serveur DHCP de signaler des proxys exploités par différents fournisseurs. Mais la liste ne remplace ni NAPTR ni SRV : le mécanisme de localisation et le choix du transport restent nécessaires.

Le mot « recours » décrit donc une transition précise. Une adresse IPv6 n’est pas une seconde liste qu’il faudrait essayer systématiquement après chaque nom. Elle vient après l’échec de résolution ou d’accès à tous les noms fournis. De même, un nom suivant n’est pas une sauvegarde automatique parce qu’il apparaît dans le paquet. L’ordre et les conditions d’essai font partie de l’information, tandis que le client conserve les décisions de résolution, de transport et de politique locale.

Ce partage avait un intérêt opérationnel : le réseau pouvait distribuer des choix de service locaux sans intégrer un proxy fixe dans chaque client. Cela n’ajoutait pas pour autant de preuve sur le service. Un serveur peut figurer sur la liste sans répondre, sans partager de transport avec le client ou sans accepter la requête. « Configuré comme préféré » et « effectivement utilisé avec succès » décrivent deux états différents.

Le canal de configuration est aussi un point de détournement

La section sécurité précise le risque. Un adversaire qui modifie ou injecte une réponse DHCP peut conduire un agent utilisateur vers un proxy SIP malveillant, susceptible d’intercepter les requêtes ou de refuser le service. Une réponse altérée peut aussi supprimer des noms qui auraient mené à des serveurs capables d’utiliser TLS, ce qui facilite l’interception.

C’est le scénario de menace du RFC, pas le récit d’une attaque observée. Il ne prétend pas qu’une adresse reçue authentifie son serveur ni que chaque nom aboutit à TLS. La réponse DHCP participe à la chaîne de confiance parce qu’elle oriente la prochaine destination de la signalisation. Les contrôles d’identité, la politique et les protections du reste du système demeurent distincts. Trouver un serveur, ce n’est pas l’authentifier.

Une option ancienne reste inscrite dans les registres actuels

RFC 9915 est aujourd’hui la spécification générale DHCPv6 et remplace RFC 8415. Le registre IANA des codes d’option DHCPv6 conserve pourtant les numéros 21 et 22 sous la référence RFC 3319 ; RFC 9243 donne ensuite des groupements YANG pour configurer les deux formes. Cette continuité atteste leur présence dans des registres et un modèle de configuration, non leur fréquence d’usage, la compatibilité des clients ou le taux d’appels réussis.

La contribution de RFC 3319 était donc plus limitée — et plus intéressante — que « DHCP trouve un serveur téléphonique ». Elle formalise une découverte hiérarchisée d’un proxy sortant local : noms d’abord, adresses ensuite sous condition. L’appel reste en aval ; l’option peut orienter la signalisation, pas certifier ce qui se passe après.

Sources