Résumé

  • RFC 5417 définit deux options distinctes, DHCPv4 et DHCPv6, qui transportent des listes ordonnées d’adresses de contrôleurs CAPWAP ; le serveur DHCP configuré fournit cette séquence.
  • L’ordre influence le premier candidat qu’un WTP doit essayer, mais ne prouve ni sa joignabilité ni son identité. L’authentification des pairs intervient ensuite avec DTLS lors de l’établissement de session.

Dans une configuration de site, l’ordre d’une liste d’AC n’est pas une sonde de santé : c’est une politique. RFC 5417 rend cette politique visible au point de terminaison sans fil (WTP) en lui permettant de recevoir une séquence de contrôleurs d’accès (AC) avant la découverte CAPWAP. Le serveur DHCP ordonne les candidats ; il ne constate pas lequel est disponible.

Les deux familles d’adresses restent séparées. L’option DHCPv4 138 transporte des adresses IPv4 de 32 bits et sa longueur doit être un multiple de quatre octets. L’option DHCPv6 52 transporte des adresses IPv6 de 128 bits, avec une longueur multiple de seize octets. Le client DHCP qui agit pour le WTP doit demander l’option concernée dans sa liste de paramètres demandés. Le serveur ne la renvoie que si sa politique est configurée et s’il dispose d’une liste d’adresses d’AC.

La séquence provient donc d’une configuration serveur ; ce n’est pas une mesure autonome de disponibilité. RFC 5417 indique que les AC figurent selon leur ordre de préférence. Le WTP peut exploiter la liste pour en trouver un et devrait essayer les adresses dans l’ordre reçu. L’ordre façonne réellement le chemin de recherche, sans devenir pour autant une garantie de service. Il ne rend pas une adresse joignable, ne mesure pas la charge des contrôleurs et ne garantit pas que le premier acceptera le WTP.

Il faut aussi éviter de fusionner les deux listes en une priorité imaginaire. RFC 5417 définit l’ordre d’une liste IPv4 et celui d’une liste IPv6, sans préciser un classement commun entre les deux familles. Si la première adresse IPv4 et la première adresse IPv6 doivent exprimer la même préférence, la configuration locale doit le rendre explicite.

Une adresse annoncée ne rend pas davantage le contrôleur digne de confiance. DHCP donne au WTP un premier indice de destination ; découverte CAPWAP et établissement de session ont d’autres fonctions. RFC 5415 décrit les messages de découverte puis le processus de session. La section de sécurité de RFC 5417 avertit qu’un attaquant capable de modifier ou d’injecter une réponse DHCP pourrait orienter le WTP vers un AC malveillant, susceptible d’intercepter des demandes d’appel ou de provoquer un déni de service. CAPWAP doit utiliser DTLS pour authentifier les pairs lors de l’établissement de la session.

Cette frontière d’authentification ne rend pas le démarrage sans importance. RFC 5417 rappelle que, dans la plupart des réseaux, DHCP distribue ces options avant l’authentification d’accès, sans protection d’intégrité ni preuve d’origine. Dans un environnement sensible, les options ne devraient pas être l’unique moyen de déterminer quel AC contacter. RFC 5415 définit d’autres méthodes de découverte que le WTP peut employer. Le mécanisme est donc en couches : DHCP propose et ordonne des candidats ; un échange ultérieur authentifié détermine si le pair est acceptable.

Les registres IANA continuent d’identifier l’option DHCPv4 138 (OPTION_CAPWAP_AC_V4) et l’option DHCPv6 52 (OPTION_CAPWAP_AC_V6), toutes deux référencées à RFC 5417. Ces attributions confirment l’existence des paramètres dans les registres ; elles ne démontrent ni leur adoption par les produits actuels ni le comportement d’un WTP après un échec.

Pour l’exploitation, l’objet utile est la chaîne complète : le WTP demande-t-il l’option ; que renvoie le serveur pour son périmètre et sa famille d’adresses ; chaque AC est-il routable et à l’écoute ; que répond la découverte CAPWAP ; et DTLS authentifie-t-il le pair attendu ? Une capture montrant l’option 138 ou 52 prouve ce que DHCP a transmis, pas que le WTP a atteint le contrôleur voulu ni établi une session de contrôle utilisable.

RFC 5417 apporte une règle limitée mais importante. Une politique DHCP peut influencer l’ordre dans lequel un équipement sans fil cherche son plan de contrôle, sans transformer une préférence configurée en élection en direct ou en verdict de sécurité. Lors d’une migration, garder les étapes distinctes simplifie la décision : la liste exprime l’intention, la découverte teste les candidats et DTLS authentifie le pair qui poursuit.

Sources