Exemples de configuration sans état

Table des matières

Renumérotation des routeurs

Principes

L'autoconfiguration avec état vise à réduire les efforts d'installation des machines IPv6, tout comme l'autoconfiguration sans état d'ailleurs. A la différence de cette dernière, elle offre une information de configuration plus riche et un contrôle sur l'affectation des paramètres de configuration.

Un paramètre de configuration est une information utile à une machine pour configurer son interface réseau de manière à ce qu'elle puisse communiquer sur son lien ou sur l'Internet. L'ensemble des paramètres de configuration comprend notamment les informations :

• d'adressage, de routage,
• du service de noms (DNS),
• du service d'information réseau (NIS)
• etc.

Attention, cependant, les informations de routage ne sont pas fournies en IPv6 par les mécanismes d'autoconfiguration avec ou sans état mais par la procédure de découverte des routeurs d'ICMPv6. Les deux techniques d'autoconfiguration ne sont pas exclusives et peuvent coexister dans un même environnement. Par exemple, une machine peut obtenir son adresse unicast globale par l'autoconfiguration sans état et récupérer les informations sur le service de noms (DNS) par l'autoconfiguration avec état.

Tout le mécanisme d'autoconfiguration avec état est bâti sur le modèle du client-serveur et repose sur l'utilisation du protocole DHCPv6 (Dynamic Host Configuration Protocol for IPv6) comme DHCP pour IPv4. La principale différence vient d'une simplification du code : le DHCP d'IPv4 n'est qu'une extension du protocole bootp avec donc des fonctionnalités limitées. Le protocole DHCPv6 sert à remettre des paramètres de configuration d'un serveur DHCP à un client IPv6.

Le client IPv6 représente une machine candidate à une connectivité globale IPv6 et demandeur d'informations de configuration pour activer cette connectivité. Le serveur DHCP constitue un point central regroupant les paramètres de configuration. Il ne se trouve pas forcément sur le même lien que le client et dans ce cas, les échanges DHCP peuvent passer par un relais. Le serveur peut maintenir la configuration de machines situées sur plusieurs liens différents. Le client DHCP doit maintenir une connectivité directe soit avec un relais DHCP, soit avec le serveur DHCP lui-même.

Le relais fonctionne comme un "proxy" DHCP, c'est-à-dire son action se limite à la transmission des messages DHCP. Il est transparent aux informations échangées et ne modifie en rien les messages DHCP du serveur et du client. Un relais encapsule les messages DHCP provenant du client dans un message DHCP au format particulier (cf figure Structure des messages de relais) et effectue l'opération inverse pour les messages provenant du serveur (à savoir désencapsule les messages du serveur pour leur remise au client). Le serveur constitue le message que doit recevoir le client, et, faute de pouvoir le joindre, il constitue un message DHCP pour le relais qui contiendra le message DHCP du client.

Afin de connaître l'état des ressources gérées (représentées par les paramètres de configuration), le serveur DHCP maintient une liste d'associations entre le paramètre attribué et le client. Comme l'adresse unicast du client est une ressource dépendant du serveur, celle-ci n'est pas utilisable par le serveur DHCP pour identifier un client. Le serveur identifie donc le client par un identifiant unique à usage exclusif de DHCP : le DUID (DHCP Unique IDentifier). Cet identifiant est généré par le client et ne doit plus en changer dans le temps. Le DUID concerne le client (le noeud) et non une interface du client. Plusieurs schémas de génération sont proposés reposant sur l'adresse de lien-local complétée par un élément qui garantit l'unicité comme par exemple une estampille temporelle. Une fois qu'un client a un DUID, il doit le conserver même s'il change d'adresse lien local.

L'adresse lien-local du client peut servir d'identifiant mais il n'existe aucune garantie qu'elle soit unique au niveau d'un domaine. Son unicité est assurée uniquement au niveau du lien. Cependant, elle présente les intérêts suivants :

• elle est déterminée par le client lors de la première phase de l'autoconfiguration (cf See Configuration automatique et contrôle),
• elle est permanente au client (il n'y a pas de re-numérotation ou de changement d'adresse tant que la carte réseau n'est pas changée).

Les affectations d'adresses à un client sont gérées par le serveur avec une notion de container appelé IA (Identity Association). Une IA est définie comme une liste (pouvant être vide) d'adresses IPv6. L'idée est que chaque client a une IA par interface et que cette IA reste affectée en permanence à l'interface. Ainsi, par ce container, la gestion de la durée de vie des adresses ou la renumérotation du client s'effectue par le serveur. Cette notion simplifie le format des messages et le contrôle des adresses.

Conformément au modèle client-serveur, les échanges se composent de requêtes et de réponses. Une transaction est souvent entamée à l'initiative d'un client par une requête DHCP. La fiabilité de la transaction est assurée par le client, qui répète sa requête DHCP jusqu'à recevoir une réponse ou obtenir la certitude que le serveur DHCP est indisponible. DHCPv6 est un protocole d'application qui se sert du protocole de transport UDP. Un client envoie les requêtes sur le port 547 du serveur et recevra les réponses par le port 546. Les messages UDP seront encapsulés classiquement dans des paquets IPv6. En plus des communications point-à-point, DHCPv6 s'appuie également sur des communications multi-destination (multicast) pour la découverte des serveurs d'un site.

Format des messages DHCPv6

L'ensemble des éléments du protocole DHCPv6 est décrit dans le document (RFC 3315). A l'instar de nombreux protocoles de l'Internet, le protocole d'échange d'informations est découplé de l'information elle-même. La nature des informations échangées peut changer et évoluer rapidement sans impacter les mécanismes de cet échange. Cette séparation assure au protocole une certaine stabilité et une propriété d'extensibilité. On retrouve dans la structure des unités de protocole ce découpage. Une unité de protocole DHCP suit le schéma classique des unités de protocole : un en-tête pour les informations du protocole lui-même, une charge utile pour les informations applicatives.

Dans la terminologie DHCP, une unité de protocole DHCPv6 est désignée par le terme message. Chaque message DHCP a un format d'en-tête identique. De ce point de vue, DHCP reprend les principes qui ont guidé à la conception du format du segment TCP : un seul format pour l'ensemble des fonctions de TCP. La motivation tient à la simplification du processus de développement du protocole.

La figure Structure des messages DHCPv6 présente la structure d'un message DHCPv6. La partie en-tête se divise en trois parties :

• L'information de commande codée sur un mot de 32 bits désigne la fonction DHCP concernée par l'échange. Cette partie contient notamment le type de message, l'identification de l'échange. Le premier champ de cette partie est toujours le champ type de message codé sur 8 bits et qui définit la fonction du message dans le protocole. Le champ transaction-ID a comme rôle comme son nom l'indique, d'identifier la transaction vis à vis du client. Il sert au client à rapprocher les réponses reçues des demandes qu'il a faites.
• L'information d'adressage sert à indiquer l'adresse IPv6 du serveur d'un échange DHCP. L'adresse du serveur contient l'adresse de l'interface utilisé par le serveur dans la transaction.
• Le champ options sert à véhiculer les informations de configurations. Cette partie est de taille variable. Son codage suit le schéma classique "TLV" à savoir le type de l'option, la longueur en octet du champ valeur qui suit et le champ valeur du paramètre. Le champ type est toujours codé sur 2 octets. Le champ longueur sur 2 octets est toujours présent, même en l'absence de valeur ou pour une valeur de longueur fixe

Les messages utilisés pour la communication serveur - relais sont différents. Un message de relais contient l'information de remise du message DHCP du serveur au client. Les messages de relais suivent le format de la See Structure des messages de relais. Le préfixe du lien indique l'interface du relais par laquelle le message DHCP a été reçu ou par laquelle il doit être envoyé. L'adresse lien-local du client contient l'adresse de l'interface à configurer du client. Le message DHCP est encapsulé dans le message de relais sous forme d'une option.

Le protocole DHCPv6 met en jeu 12 messages DHCP différents :

• Sollicitation DHCP (DHCP Solicit) :
  Message d'interrogation de présence de serveurs DHCP. Il est émis vers un serveur ou un relais DHCP. Un client émet un tel message pour localiser les serveurs DHCP.

• Annonce DHCP (DHCP Advertise) :
  Message de présence de serveurs DHCP. Il est émis en réponse à un message sollicitation DHCP afin de communiquer l'adresse IP d'un serveur DHCP. Le destinataire est le client s'il est sur le même lien que le serveur sinon ce message est adressé au relais du client.

• Requête DHCP (DHCP Request) :
  Message de demande de paramètres de configuration de la part d'un client sans adresse.
• Confirmation DHCP (DHCP Confirm) :
  Message de demande de confirmation de validité des paramètres alloués au client.
• Renouvellement DHCP (DHCP Renew) :
  Message de demande de prolongation de l'adresse IP affectée
• Ré affectation DHCP (DHCP Rebind) :
  Identique au précédent message mais un autre serveur DHCP peut répondre, pas obligatoirement celui qui a alloué l'adresse IP.
• Réponse DHCP (DHCP Reply) : Message émis par le serveur suite à une demande du client. Il contient les valeurs des paramètres de configuration demandés.
• Libération DHCP (DHCP Release) :
  Message d'indication du client de libération des adresses IP préalablement allouées par le serveur.
• Refus DHCP (DHCP Decline) :
  Message d'indication du client qu'une ou plusieurs adresses affectées sont déjà utilisées sur son lien.
• Notification de reconfiguration DHCP (DHCP Reconfigure-init) :
  Message émis par le serveur pour informer le client qu'il a de nouvelles valeurs pour les paramètres de configuration. Le client doit alors commencer une nouvelle transaction pour acquérir ces informations.
• Encapsulation relais (Relay-Forward) :
  Message du relais pour véhiculer les messages du client vers le serveur. Le message du client est encapsulé dans ce message.
• Encapsulation serveur (Relay-Reply) :
  Message généré par le serveur contenant un message pour le client. Ce message est à destination du relais qui extraira un message pour le client afin de le transmettre sur le lien du client.

Les informations échangées entre le client et le serveur DHCP se font au moyen d'options. Les informations se divisent en trois catégories (cf. tableau Options de DHCPv6).

• les informations temporaires. Elles concernent les ressources réseaux demandées par le client et prêtées par le serveur pour une durée déterminée. Actuellement, le seul type de ressource temporaire est l'adresse IP dont la gestion est faite par la notion d'IA.
• Les informations générales. Elles traitent de l'ensemble des paramètres de configuration habituellement fournies pour la configuration d'une machine IPv6.
• Les informations spécifiques à DHCP.

Acquisition de l'adresse du serveur DHCP

En premier lieu la machine désirant se configurer doit localiser un serveur. Pour cela, elle envoie le message sollicitation DHCP. Pour construire ce messages, elle remplit le champ d'identification de la transaction et ajoute l'option DUID. Ensuite elle envoie sa requête en mode multicast vers tous les agents DHCP du lien (adresse FF02::1:2). Le groupe des agents comprend à la fois les serveurs et les relais DHCP d'un domaine d'administration. Ce message ne peut être routé car le client utilise son adresse lien local. Si le serveur n'est pas sur le même lien que le client, un relais doit y être. C'est pourquoi l'adresse multicast est de portée locale au lien.

Dans le cas où cette transaction passe par un relais, le message de sollicitation est encapsulé dans le champ option d'un message encapsulation relais avec comme préfixe celui de l'interface sur laquelle le relais a reçu ce message. Selon la configuration des relais, le message est émis à un serveur DHCP en mode unicast vers une liste de serveurs ou en mode multicast. Dans ce dernier cas, l'adresse multicast utilisée est celle du groupe des serveurs DHCP (FF05::1:3) du site ou une adresse de groupe propre au site.

Quand le message sollicitation DHCP arrive au serveur, il renvoie un message annonce DHCP en prenant bien soin d'indiquer son adresse dans le champ "adresse du serveur" et de recopier l'identification de transaction du message de sollicitation. Le serveur peut mettre une option préférence. La préférence codée sur 8 bits indique la volonté du serveur de servir le client. Le client doit retenir le serveur qui a la valeur de préférence la plus forte. Une certaine forme de répartition des clients entre les serveurs peut être ainsi effectuée. Le message d'annonce DHCP est ensuite émis en unicast au client directement ou via le relais.

Comme les communications s'appuient sur le protocole de transport non fiable UDP, DHCP inclus un mécanisme de fiabilisation très simple. Chaque message de requête DHCP émis doit être acquitté par un autre message DHCP. L'initiateur d'une transaction DHCP détecte la perte au moyen d'un temporisateur. A l'expiration du temporisateur, le message DHCP est ré-émis à l'identique.

Acquisition de l'adresse unicast globale

Dès que le client a trouvé un serveur, il peut à présent obtenir les informations de configuration. Pour ce faire, il envoie une requête DHCP au serveur «préféré», en remplissant le champ options avec les paramètres qu'il souhaite obtenir en retour. Lorsqu'une telle requête arrive au serveur, celui-ci construit un message de réponse DHCP en y incluant sous forme d'options, les informations de configuration demandées par le client. A chaque requête du client, l'option DUID d'identification du client est présente.

Dans le cas d'une acquisition d'une adresse unicast globale, l'option Association d'Identification (IA) est placée dans le message de requête DHCP. Cette option IA contient toutes les informations relatives au contrôle des allocations des adresses IP. Le serveur complète l'option et conserve une trace de ce prêt. Après vérification que le message est bien une réponse à sa demande, le client regarde les différents champs et peut ainsi commencer sa configuration. Ensuite le client doit entamer une procédure DAD (Détection d'Adresse Dupliquée). En cas d'échec de la procédure, l'adresse doit être restituée au serveur au moyen du message de refus DHCP. Dans le cas des messages renouvellement DHCP ou ré-affectation DHCP, si l'adresse donnée dans l'option IA est celle d'une adresse déjà assignée à l'interface (cette situation correspond à un prolongement de la durée de vie), la procédure DAD n'a pas lieu d'être déroulée.

Un client peut restituer son adresse IP selon 2 méthodes :

• par une notification explicite au moyen du message de libération DHCP. Le message de libération est acquitté par le message de réponse DHCP. L'adresse IP restituée est mise dans l'option IA.
• en n'étendant pas la durée de vie de la validité de son adresse. Lorsque la durée de vie de l'état préféré de l'adresse est consommée, le client doit prolonger auprès du serveur les durées de vie des états de son adresse. Sinon une fois que la période de validité de l'adresse est épuisée, l'adresse ne doit plus être utilisée. Elle est potentiellement affectable par le serveur à un autre client.

Exemple

Pour illustrer le fonctionnement du protocole DHCPv6 nous allons prendre le cas simple (absence de relais) où une machine après avoir calculé son adresse lien-local souhaite récupérer son adresse unicast globale d'un serveur DHCP qui se situe sur le même lien. La figure Transactions DHCPv6 sans relais présente les échanges nécessaires.

Mise à jour de configuration

DHCP prévoit également que des transactions peuvent être déclenchées à l'initiative du serveur. Cette situation correspond aux cas de l'ajout d'un nouveau réseau, de la renumérotation de réseau ou du changement de situation des serveurs (d'impression, de noms, etc.) ou à l'ajout de nouveaux services. La méthode proposée par le protocole DHCP repose sur l'envoi du message de notification de reconfiguration DHCP. Quand un client reçoit un tel message, il doit commencer une transaction requête/réponse DHCP avec le serveur. Celui-ci indique par l'option ORO quelles sont informations de configurations qui ont changées ou quelles sont celles qui ont été ajoutées. Le client pourra alors inclure dans sa demande les options correspondantes afin de récupérer les nouvelles valeurs. Le message de notification de reconfiguration DHCP est émis par le serveur en unicast à chaque client impliqué par la reconfiguration.

Authentification des messages

Un administrateur peut vouloir assurer l'authentification de la source et l'intégrité du contenu des messages DHCP pour se protéger des attaques décrites dans See [Prigent-id]. Par exemple, cette fonctionnalité est indispensable dans le cas du message Démarrage d'une reconfiguration DHCP, ceci empêche que des clients entame des transactions de reconfiguration, la source de ce message n'est pas un serveur DHCP. Le mécanisme d'authentification de DHCPv6 repose sur le même principe d'authentification de DHCP de IPv4 (RFC 3118) à savoir sur une option d'authentification. DHCP et mobilité

L'atout majeur de l'autoconfiguration est, comme son nom l'indique, la possibilité pour toute nouvelle machine d'obtenir, sans l'intervention humaine, une identité IP sur le réseau où elle se trouve. Un n?ud mobile doit au moyen d'un protocole transmettre à son agent mère (cf. Mobilité dans IPv6) sa nouvelle adresse. Dans See [Dupont-id], il est proposé d'utiliser DHCPv6 pour assurer cet échange.

Re-numérotation de réseau avec DHCP

DHCP peut servir d'outil pour la re-numérotation d'un réseau. Cette tâche peut être réalisée selon deux méthodes:

• re-numérotation passive. Pour que cette méthode soit utilisable, les durées de vie des adresses allouées au client doivent être courtes. Quand l'administrateur souhaite re-numéroter un réseau, il met, sur ses serveurs, une valeur nulle à la durée de vie des adresses réseau en service. Les clients ne pourront plus prolonger la durée de vie de leur adresse. Ils demanderont donc une adresse dans le nouveau plan d'adressage. Quand la durée de vie de toutes les adresses de l'ancien plan d'adressage aura expiré, le réseau pourra être considéré re-numéroté.
• re-numérotation active. L'administrateur force la re-numérotation du réseau au moyen de la reconfiguration de DHCP. Les serveurs génèrent un message démarrage d'une reconfiguration DHCP pour chacun de leur client devant subir la re-numérotation. Ceux-ci entame une transaction Requête/Réponse DHCP portant sur l'adresse. La réponse du serveur contient l'adresse originale avec une durée de vie mise à nulle et la nouvelle adresse valide.

Avenir de DHCPv6

Au moment de la rédaction de ce livre, le protocole était toujours dans un état de document de travail. Ceci est principalement dû à l'inhérente complexité du protocole. Sa mise en oeuvre est compliquée par le nombre important de messages avec des formats différents et des en-têtes de longueur variable. Seules deux distributions sont disponibles (dont une incomplète). Le manque d'expérience sur ce protocole est l'autre raison de son blocage à l'état de document de travail.

On peut se demander s'il existe un véritable intérêt pour DHCPv6, en effet ce protocole est fortement lié à IPv4 et a été largement utilisé pour parer au manque d'adresses. Initialement, les stations de travail Sun utilisaient RARP comme protocole pour trouver leur adresse IP (en fonction de l'adresse MAC de la station) puis calculer quelques paramètres essentiels (comme le nom du fichier contenant le programme d'amorçage, composé à partir de l'adresse MAC, ce fichier étant téléchargé dans la phase suivante par TFTP). Ce système n'était pas très satisfaisant. L'IETF a donc standardisé un protocole fournissant un service identique, BOOTP (RFC 0951). Ce protocole a été ensuite étendu pour fournir d'autres paramètres que le nom du fichier du programme d'amorçage, regroupés sous le nom «BOOTP Vendor Information Extensions» (RFC 1048).

DHCP est un extension de BOOTP gérant l'allocation dynamique d'adresses IP (les leases/baux). Les implémentations de DHCP sont conçues afin de gérer ces adresses comme une ressource rare. Dans le cadre d'IPv6, les problèmes sont totalement différents et donc les protocoles devraient aussi l'être :

• tous les noeuds peuvent communiquer localement en formant des adresses de portée réduite générées automatiquement ou conservées dans de la mémoire stable (cas général des routeurs) ;
• une machine peut utiliser la configuration sans état pour acquérir des adresses globales ;
• un sous-réseau IPv6 dispose de 2^64 adresses, donc une adresse n'est pas une ressource rare ;
• enfin le (RFC 2462) définit la configuration avec état comme un service qui attribue les adresses permanentes aux machines, donc plus comme BOOTP que DHCP.

Cela conduit à deux problèmes de fond :

• la notion d'adresses temporaires «à la DHCP» a peu de sens en IPv6 ;
• même l'attribution centralisée d'adresses globales n'a pas beaucoup d'intérêt car la configuration sans état peut toujours être utilisée (dans les faits elle est utilisée depuis plus de six ans sans que le besoin d'un autre mécanisme se fasse réellement ressentir).

Par contre, un système optionnel de gestion des adresses, en particulier faisant l'interfaçage avec les fonctions de contrôle d'accès au réseau peut avoir un intérêt lorsque le protocole IPv6 sera utilisé dans la téléphonie de troisième génération.

Il est aussi nécessaire de disposer de moyens pour découvrir les paramètres d'un petit nombre de services de base comme le serveur de noms, le domaine DNS, ou les imprimantes disponibles. Plusieurs pistes alternatives à DHCPv6 sont envisagées comme l'utilisation d'adresses anycast.

Exemples de configuration sans état

Table des matières

Renumérotation des routeurs