Configuration avec état :DHCPv6 - Revision history

Ltoutain at 13:41, 22 June 2009

2009-06-22T13:41:09Z

Bruno Deniaud: /* Format des messages DHCPv6 */

2006-02-09T16:05:38Z

‎Format des messages DHCPv6

212.234.161.2: /* Format des messages DHCPv6 */

2006-02-09T14:55:18Z

‎Format des messages DHCPv6

212.234.161.2: /* Principes */

2006-02-09T14:54:37Z

‎Principes

Bruno Deniaud: /* Avenir de DHCPv6 */

2006-02-08T15:12:30Z

‎Avenir de DHCPv6

Bruno Deniaud: /* Authentification des messages */

2006-02-08T15:11:36Z

‎Authentification des messages

Bruno Deniaud: /* Authentification des messages */

2006-02-08T15:10:03Z

‎Authentification des messages

Bruno Deniaud: /* Avenir de DHCPv6 */

2006-02-08T15:07:11Z

‎Avenir de DHCPv6

Bruno Stévant at 22:49, 7 February 2006

2006-02-07T22:49:17Z

Bruno Stévant at 21:47, 30 January 2006

2006-01-30T21:47:11Z

@@ Line 152: / Line 152: @@
 * 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 264 adresses, donc une adresse n'est pas une ressource rare ;
+* 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.

@@ Line 83: / Line 83: @@
 |Message client || Pour l'encapsulation du message DHCP du client par le relais
 |-
-|Message serveur ||Pour encapsulation du message DHCP du serveur via un relais
+|Message serveur ||Pour l'encapsulation du message DHCP du serveur via un relais
 |-style="background:silver"
 |DSTM adresse IPv4 || Informe le client que l'adresse allouée est une adresse IPv4 mappée IPv6

@@ Line 81: / Line 81: @@
 |Recherche de domaine || Liste de noms de domaines qu'un client peu utiliser dans ses recherches de noms DNS.
 |-style="background:silver"
-|Message client || Pour encapsulation du message DHCP du client par le relais
+|Message client || Pour l'encapsulation du message DHCP du client par le relais
 |-
 |Message serveur ||Pour encapsulation du message DHCP du serveur via un relais

@@ Line 15: / Line 15: @@
 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 avec soit avec un relais DHCP, soit avec le serveur DHCP lui-même.
+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.

@@ Line 146: / Line 146: @@
 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 See [RFC0951]. 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» See [RFC1048].
+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 :
@@ Line 153: / Line 153: @@
 * une machine peut utiliser la configuration sans état pour acquérir des adresses globales ;
 * un sous-réseau IPv6 dispose de 264 adresses, donc une adresse n'est pas une ressource rare ;
-* enfin le See [RFC2462] définit la configuration avec état comme un service qui attribue les adresses permanentes aux machines, donc plus comme BOOTP que DHCP.
+* 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 :

@@ Line 130: / Line 130: @@
 == 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 (RFC3118) à savoir sur une option d'authentification.
+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é

@@ Line 144: / Line 144: @@
 == 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 ?uvre 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.
+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 See [RFC0951]. 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» See [RFC1048].

← Older revision		Revision as of 22:49, 7 February 2006
Line 1:		Line 1:
−	{{suivi\|Exemples de configuration sans état\|Exemples de configuration sans état\|Renumérotation des routeurs\|Renumérotation des routeurs}}	+	{{suivi\|Exemples de configuration sans état\|Exemples de configuration sans état\|Renumérotation des routeurs\|Renumérotation des routeurs}}
	== Principes ==		== Principes ==

← Older revision		Revision as of 21:47, 30 January 2006
Line 1:		Line 1:
		+	{{suivi\|Exemples de configuration sans état\|Exemples de configuration sans état\|Renumérotation des routeurs\|Renumérotation des routeurs}}
	== Principes ==		== Principes ==

Line 162:		Line 163:

	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.		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.
		+
		+	{{suivi\|Exemples de configuration sans état\|Exemples de configuration sans état\|Renumérotation des routeurs\|Renumérotation des routeurs}}