JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Administration d'Oracle Solaris : Services IP     Oracle Solaris 11 Information Library (Français)
search filter icon
search icon

Informations document

Préface

Partie I Administration TCP/IP

1.  Planification du développement du réseau

2.  Eléments à prendre en compte lors de l'utilisation d'adresses IPv6

3.  Configuration d'un réseau IPv4

4.  Activation d'IPv6 sur le réseau

5.  Administration d'un réseau TCP/IP

6.  Configuration de tunnels IP

7.  Dépannage des problèmes de réseau

8.  Référence IPv4

9.  Référence IPv6

Implémentation IPv6 sous Oracle Solaris

Fichiers de configuration IPv6

Fichier de configuration ndpd.conf

Fichier de configuration /etc/inet/ipaddrsel.conf

Commandes associées à IPv6

Commande ipaddrsel

Commande 6to4relay

Modification de la commande netstat en vue de la prise en charge IPv6

Modification de la commande snoop en vue de la prise en charge IPv6

Modification de la commande route en vue de la prise en charge IPv6

Modification de la commande ping en vue de la prise en charge IPv6

Modification de la commande traceroute en vue de la prise en charge IPv6

Démons liés à IPv6

Démon in.ndpd pour Neighbor Discovery

Démon in.ripngd, pour routage IPv6

Démon inetd et services IPv6

Protocole ND IPv6

Messages ICMP de la détection des voisins

Processus de configuration automatique

Obtention d'une publication de routeur

Variables de préfixes de configuration

Unicité des adresses

Sollicitation de voisin et inaccessibilité

Algorithme de détection d'adresse dupliquée

Publications de proxy

Equilibrage de charge entrante

Modification d'adresse lien-local

Comparaison du protocole ND et du protocole ARP et autres protocoles IPv4

Routage IPv6

Publication de routeur

Préfixes de publication de routeurs

Messages de publication de routeurs

Extensions IPv6 de services d'assignation de noms Oracle Solaris

Extensions DNS pour IPv6

Modifications apportées aux commandes de services de noms

Prise en charge IPv6 de NFS et RPC

Prise en charge d'IPv6 sur ATM

Partie II DHCP

10.  A propos de DHCP (présentation)

11.  Administration du service DHCP ISC

12.  Configuration et administration du client DHCP

13.  Commandes et fichiers DHCP (référence)

Partie III IPsec

14.  Architecture IPsec (présentation)

15.  Configuration d'IPsec (tâches)

16.  Architecture IPsec (référence)

17.  Protocole IKE (présentation)

18.  Configuration du protocole IKE (tâches)

19.  Protocole IKE (référence)

20.  IP Filter dans Oracle Solaris (présentation)

21.  IP Filter (tâches)

Partie IV Performances du réseau

22.  Présentation de l'équilibreur de charge intégré

23.  Configuration de l'équilibreur de charge intégré (tâches)

24.  Protocole de redondance de routeur virtuel (VRRP) (Présentation)

25.  Configuration VRRP - Tâches

26.  Implémentation du contrôle de congestion

Partie V Qualité de service IP (IPQoS)

27.  Présentation d'IPQoS (généralités)

28.  Planification d'un réseau IPQoS (tâches)

29.  Création du fichier de configuration IPQoS (tâches)

30.  Démarrage et maintenance d'IPQoS (tâches)

31.  Utilisation de la comptabilisation des flux et de la collecte statistique (tâches)

32.  IPQoS en détails (référence)

Glossaire

Index

Protocole ND IPv6

IPv6 présente le protocole Neighbor Discovery, comme décrit dans le document RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). Pour une présentation des principales fonctionnalités de Neighbor Discovery, reportez-vous à la section Présentation du protocole de détection de voisins IPv6 du manuel Guide d’administration système : services IP.

Cette section décrit les fonctionnalités suivantes du protocole ND :

Messages ICMP de la détection des voisins

La détection de voisins définit cinq nouveaux messages ICMP (Internet Control Message Protocol, protocole de messages de contrôle Internet). Les messages remplissent les fonctions suivantes :

Processus de configuration automatique

Cette section comprend une présentation des étapes typiques effectuées par une interface lors d'une configuration automatique. La configuration automatique s'effectue uniquement sur des liaisons compatibles multicast.

  1. Une interface compatible multicast est activée, par exemple, lors du démarrage système d'un noeud.

  2. Le noeud démarre le processus de configuration automatique en générant une adresse lien-local pour l'interface.

    L'adresse lien-local est formée à partir de l'adresse MAC (Media Access Control) de l'interface.

  3. Le noeud envoie un message de sollicitation de voisin contenant l'adresse lien-local provisoire en guise de cible.

    Le message a pour objectif de vérifier que l'adresse possible n'est pas déjà utilisée par un autre noeud sur la liaison. Une fois la vérification effectuée, l'adresse lien-local peut être assignée à l'interface.

    1. Si un autre noeud utilise déjà l'adresse proposée, celui-ci renvoie une publication de voisin indiquant que l'adresse est déjà en cours d'utilisation.

    2. Si un autre noeud tente également d'utiliser la même adresse, le noeud envoie également une sollicitation de voisinage pour la cible.

      Le nombre de transmissions ou de retransmissions de sollicitation de voisins, ainsi que le temps d'attente entre sollicitations, sont spécifiques aux liaisons. Au besoin, vous pouvez définir ces paramètres.

  4. Si un noeud détermine que son adresse lien-local possible n'est pas unique, la configuration automatique est interrompue. Dans ce cas, vous devrez configurer manuellement l'adresse lien-local de l'interface.

    Pour simplifier la récupération, vous pouvez fournir un autre ID d'interface qui remplace l'identifiant par défaut. Ensuite, le mécanisme de configuration automatique peut reprendre, en utilisant le nouvel ID d'interface, qui est à priori unique.

  5. Lorsqu'un noeud détermine l'unicité de sa future adresse lien-local, il assigne celle-ci à l'interface.

    Le noeud dispose alors d'une connectivité de niveau IP avec les noeuds voisins. Les étapes restantes de la configuration automatique sont effectuées exclusivement par les hôtes.

Obtention d'une publication de routeur

La phase suivante de la configuration automatique consiste à obtenir une publication de routeur ou à déterminer une absence totale de routeurs. Si les routeurs sont présents, ils envoient des publications de routeur qui spécifient le type de configuration automatique que doit effectuer un hôte.

Les routers envoient des publications de routeur à intervalles réguliers. Cependant, le temps d'attente entre publications successives est en règle générale plus long que le temps d'attente possible d'un hôte effectuant la configuration automatique. Afin d'obtenir une publication dans les plus brefs délais, un hôte envoie une ou plusieurs sollicitations de routeur au groupe multicast tous routeurs.

Variables de préfixes de configuration

La publication de routeur contient également des variables de préfixe avec des informations utilisées par la configuration automatique d'adresse sans état pour la génération de préfixes. Le champ de configuration automatique d'adresse sans état dans les publications de routeur sont traitées indépendamment. Un champ d'option contenant les informations de préfixe, l'indicateur de configuration automatique d'adresse, indique si l'option s'applique également à la configuration automatique sans état. Si le champ d'option s'y applique, des champs d'option supplémentaires contiennent un préfixe de sous-réseau avec des valeurs de durée de vie. Ces valeurs indiquent la durée de validité et de préférence des adresses créées à partir du préfixe.

Dans la mesure où les routeurs génèrent régulièrement des publications de routeur, les hôtes reçoivent de nouvelles publications en continu. Les hôtes compatibles IPv6 traitent les informations contenues dans chaque publication. Les hôtes ajoutent des informations. Ils actualisent également les informations reçues dans les publications précédentes.

Unicité des adresses

Pour des raisons de sécurité, l'unicité de toutes les adresses doit être vérifiée, préalablement à leur assignation à une interface. La situation est différente pour les adresses créées par configuration automatique sans état. L'unicité d'une adresse est déterminée principalement par la partie de l'adresse formée à partir d'un ID d'interface. Par conséquent, si un noeud a déjà vérifié l'unicité d'une adresse lien-local, il est inutile de tester les adresses supplémentaires individuellement. Les adresses doivent être créées à partir du même ID d'interface. Toutes les adresses obtenues manuellement doivent par contre être testées individuellement pour leur unicité. Les administrateurs système de certains sites pensent que les bénéfices de la détection d'adresses dupliquées ne vaut pas le temps système qu'elle utilise. Pour ces sites, l'utilisation de la détection des adresses dupliquées peut être désactivée en définissant un indicateur de configuration par interface.

Pour accélérer le processus de configuration automatique, un hôte peut générer son adresse lien-local et vérifier son unicité, pendant que l'hôte attend une publication de routeur. Un routeur peut retarder une réponse à une sollicitation de routeur de quelques secondes. Par conséquent, le temps total nécessaire à la configuration automatique peut être bien plus long si les deux étapes sont effectuées en série.

Sollicitation de voisin et inaccessibilité

La détection de voisins utilise les messages de sollicitation de voisin pour déterminer si plusieurs noeuds sont assignés à la même adresse unicast. La détection d'inaccessibilité de voisin détecte la défaillance d'un voisin ou du chemin de transfert du voisin. Cette détection nécessite une confirmation de la réception des paquets par le voisin. La détection d'inaccessibilité de voisins détermine également que les paquets sont traités correctement par la couche IP du noeud.

La détection d'inaccessibilité de voisin utilise les confirmations en provenance de deux sources : les protocoles de couche supérieure et les messages de sollicitation de voisin. Lorsque c'est possible, les protocoles de couche supérieure fournissent une confirmation positive de la progression d'une connexion. Par exemple, à la réception d'accusés de réception TCP, il est confirmé que les données précédemment envoyées ont été livrées correctement.

Lorsqu'un noeud n'obtient pas de confirmation en provenance des protocoles de couche supérieure, le noeud envoie des messages de sollicitation de voisins. Ces messages sollicitent des publications de voisinage en tant que confirmation d'accessibilité à partir du prochain saut. Pour réduire le trafic réseau inutile, les messages de sonde sont envoyés uniquement au noeud envoyant des paquets activement.

Algorithme de détection d'adresse dupliquée

Pour garantir que toutes les adresses configurées sont susceptibles d'être uniques sur un lien donné, les noeuds exécutent un algorithme de détection d'adresse dupliquée sur les adresses. Les noeuds doivent exécuter l'algorithme avant d'assigner les adresses à une interface. L'algorithme de détection d'adresses dupliquées est exécuté sur toutes les adresses.

Le processus de configuration automatique décrit dans cette section s'applique uniquement aux hôtes et non aux routeurs. Dans la mesure où la configuration automatique utilise des informations publiées par les routeurs, ces derniers doivent être configurés différemment. Cependant, les routeurs génèrent des adresses lien-local à l'aide du mécanisme décrit dans ce chapitre. En outre, les routeurs doivent réussir l'algorithme de détection d'adresses dupliquées sur toutes les adresses préalablement à l'assignation d'une adresse à une interface.

Publications de proxy

Un routeur qui accepte les paquets à la place d'une adresse cible peut émettre des publications de voisin impossibles à ignorer. Le routeur peut accepter des paquets pour une adresse cible incapable de répondre aux sollicitations de voisins. L'utilisation de proxy n'est actuellement pas spécifiée. Cependant, la publication de proxy pourrait être utilisée pour la gestion de cas comme ceux de noeuds mobiles qui ont été déplacés hors liaison. Notez que l'utilisation de proxy n'est pas destinée à l'être en tant que mécanisme général de gestion des noeuds qui n'implémentent pas ce protocole.

Equilibrage de charge entrante

Les noeuds avec interfaces répliquées peuvent avoir besoin d'équilibrer la charge de la réception de paquets entrants sur plusieurs interfaces réseau situées sur la même liaison. Ces noeuds possèdent plusieurs adresses lien-local assignées à la même interface. Par exemple, un pilote de réseau unique peut représenter plusieurs cartes d'interface réseau en tant qu'interface logique unique possédant plusieurs adresses lien-local.

La gestion de l'équilibrage de charge s'effectue en autorisant les routeurs à omettre l'adresse lien-local source des paquets de publication de routeur. Par conséquent, les voisins doivent utiliser les messages de sollicitation de voisin afin de connaître les adresses lien-local des routeurs. Les messages renvoyés de publication des voisins peuvent contenir des adresses lien-local différentes, selon l'adresse qui a envoyé la demande.

Modification d'adresse lien-local

Un noeud qui sait que son adresse lien-local a été modifiée peut envoyer des paquets de publication de voisins multicast non sollicités. Le noeud peut envoyer des paquets multicast à tous les noeuds pour une mise à jour des adresses lien-local mises en cache qui ne sont plus valides. L'envoi de publications non sollicitées constitue uniquement une amélioration des performances. L'algorithme de détection d'inaccessibilité des voisins assure la fiabilité de la détection de la nouvelle adresse par le noeud, bien que le temps d'attente risque d'être légèrement plus long.

Comparaison du protocole ND et du protocole ARP et autres protocoles IPv4

La fonctionnalité du protocole ND (Neighbor Discovery, détection des voisins) IPv6 correspond à une combinaison des protocoles IPv4 : ARP (Address Resolution Protocol, protocole de résolution d'adresse), détection de routeur ICMP (Internet Control Message Protocol, protocole de messages de contrôle Internet) et redirection ICMP. IPv4 ne possède pas de protocole ou de mécanisme accepté par tous pour la détection d'inaccessibilité. Cependant, les exigences de l'hôte spécifient les algorithmes possibles pour la détection de passerelles bloquées. La détection de passerelles bloquées est un sous-ensemble des problèmes résolus par la détection d'inaccessibilité de voisins.

La liste suivante compare le protocole de détection de voisins à la suite de protocoles IPv4 associés.