Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

RFC 7788: Home Networking Control Protocol

Date de publication du RFC : Avril 2016
Auteur(s) du RFC : M. Stenberg, S. Barth (Independent), P. Pfister (Cisco)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF homenet
Première rédaction de cet article le 23 avril 2016


Ce nouveau protocole, HNCP (Home Networking Control Protocol), est conçu pour la domotique. Son rôle est de distribuer de l'information de configuration (les services comme celui d'impression, par exemple) à toutes les machines de la maison. C'est un profil (une instance particulière) du protocole DNCP du RFC 7787.

Cet HNCP est issu du projet Homenet, visant à créer à la maison des réseaux non gérés (M. Michu a autre chose à faire) et non limités à un seul lien (donc, avec des routeurs). L'architecture d'Homenet est décrite dans le RFC 7368. Dans ce cadre Homenet, HNCP doit permettre de :

  • découvrir les frontières du réseau (qu'est-ce qui est extérieur et qu'est-ce qui est intérieur), ce qui sera nécessaire pour la sécurité,
  • distribuer les préfixes IP (RFC 7695),
  • fournir l'accès à un service de résolution de noms.

HNCP n'est pas un protocole de routage (quoique on puisse considérer que le routage, c'est distribuer de l'information de configuration, mais HNCP n'est pas prévu pour cela), il faut l'utiliser avec un protocole de routage comme Babel (RFC 6126).

Comme HNCP est un profil de DNCP, il en hérite les caractéristiques (RFC 7787). Par exemple, il n'est pas adapté à de l'information très changeante. C'est pour cela que, pour la résolution de noms, HNCP distribue les adresses des serveurs de noms, mais n'assure pas cette fonction lui-même.

Le RFC sur DNCP décrit les points laissés libres dans DNCP et qu'un profil de DNCP doit spécifier (RFC 7787, section 9). La section 3 de notre RFC sur HNCP précise ces points :

  • HNCP est transporté sur UDP, port 8231, sur IPv6, bien sûr.
  • Le trafic est sécurisé par DTLS, port 8232.
  • HNCP ne marche que sur des réseaux capables de multicast, comme Ethernet (ce qui permet de découvrir les voisins facilement). Il est recommandé que l'identificateur d'interface soit dérivé de l'adresse IPv6.
  • L'identificateur de chaque nœud du réseau est choisi au hasard. (En cas - improbable - de collision, on recommence avec un nouvel identificateur.)
  • La fonction de condensation utilisée est MD5 (RFC 1321).
  • Les paramètres Trickle (RFC 6206) sont k=1, Imin=200ms, Imax=7.

Je n'ai pas d'expérience pratique avec HNCP donc je vais passer rapidement sur le reste du RFC. Parmi les points amusants à noter :

  • HNCP permet la configuration complète des adresses IP (section 6). Les nœuds situés aux frontières du réseau domestique apprennent du FAI les préfixes IP publics à utiliser (par exemple en DHCP, cf. RFC 3633), et les diffusent en HNCP. L'algorithme du RFC 7695 est utilisé pour répartir ces préfixes en sous-préfixes pour les différents liens (rappelez-vous que HNCP permet d'avoir un réseau domestique composé de plusieurs liens séparés par des routeurs.)
  • Les adresses IP des nœuds sont typiquement attribuées par le mécanisme du RFC 7217, qui dérive une adresse d'un certain nombre de paramètres du réseau local et de la machine qui se configure. (Ce qui permet d'avoir des adresses IP stables mais imprévisibles et qui ne permettent pas de traçabilité quand on change de réseau.) Les machines non-HNCP (section 7) sont, elles, configurées par les moyens classiques, comme SLAAC (RFC 4861).
  • La résolution de noms et la découverte des services sont évidemment des fonctions essentielles. L'utilisateur ne s'amuserait pas s'il devait manipuler des adresses IPv6. Chaque routeur HNCP fournit un nom pour les réseaux qu'il gère et le diffuse en HNCP. Il a aussi un nom pour lui-même. Le TLD utilisé est .home (qui, c'est à noter, ne figure pas dans le registre des noms de domaine spéciaux).

Comme tous les protocoles instanciés à partir de DNCP, HNCP transporte l'information sous forme de TLV (section 10). Ces TLV peuvent être emboîtés (un sous-TLV dans la partie Valeur d'un TLV). Parmi les TLV possibles (la liste complète est dans un registre IANA), on trouve :

  • « Version HNCP », type 32, qui permet d'indiquer aux voisins quelle version de HNCP on gère. Cela ne se fait pas sous forme d'un numéro de version mais sous forme d'un groupe de bits décrivant les capacités du nœud HNCP.
  • « Connexion extérieure », type 33, rassemble les informations envoyées par un FAI, et que le réseau local doit connaitre. « Préfixe délégué », type 34, sous-TLV du précédent, indique les préfixes IP.
  • « Nom de domaine », type 40, est le suffixe qui sera utilisé pour nommer les machines et services, alors que « Nom de machine », type 41, indique le nom d'une machine et son adresse IP.
  • Etc (il y en a beaucoup).

La section 11 du RFC résume les exigences qui pèsent sur les nœuds d'un réseau HNCP. En plus de gérer le protocole HNCP lui-même, ils doivent aussi, s'ils sont routeurs, respecter le RFC 7084, qui spécifie les règles (légèrement assouplies dans notre RFC sur HNCP) que doivent suivre les routeurs IPv6 situés chez l'utilisateur.

Enfin, un petit mot sur la sécurité (section 12) : HNCP est conçu pour être simple pour l'utilisateur et pour marcher tout seul. Sa sécurité sera donc forcément très faible : un réseau à la maison sans administrateur système professionnel offrira plein de trous à un éventuel attaquant (le RFC 7368 parle de la sécurité des réseaux domotiques). On ne peut pas avoir à la fois le beurre (l'auto-configuration) et l'argent du beurre (la sécurité).

Quelles sont les mises en œuvre de HNCP aujourd'hui ? Il y a, en logiciel libre, hnetd (qui est accessible également sous forme de paquetages pour OpenWrt, depuis la version Barrier Breaker - 14.07 - en juillet 2014). hnetd fait partie du projet HomeWrt. Complètement indépendant de hnetd, il existe également shncpd. On peut aussi citer pysyma, écrit en Python.

En non-libre, il y a du HNCP en cours de développement dans des environnements aussi différents que les routeurs Cisco ou D-Link, les systèmes Nest, le système Xfinity de Comcast... Il parait même que c'est prévu pour les Freebox mais je n'ai pas trouvé de détails à ce sujet. D'autre part, HNCP est apparemment cité dans la spécification (fermée et non publique) Thread.

Les protocoles Homenet sont en développement depuis longtemps et, si vous allez à des salons ou des conférences, vous avez certainement vu des démonstrations utilisant HNCP.

Et si vous aimez l'histoire des protocoles, notez que HNCP, à l'origine, était prévu pour assurer l'auto-configuration de routeurs dans un réseau OSPF (RFC 7503). Cette idée d'« auto-configuration OSPF » n'a pas rencontré un grand succès car tout le monde n'aime pas OSPF et aurait préféré découpler le routage (OSPF, Babel, etc) de la distribution d'informations. HNCP, protocole limité à cette distribution, était né. Il a ensuite été abstrait dans le protocole DNCP (RFC 7787), dont HNCP n'est qu'un profil.


Téléchargez le RFC 7788

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)